Re: [STDS-802-3-EPOC] [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Duane,
These numbers are quite different from what was shown at the previous
meetings in terms of complexity. I'd suggest you sit down with IC designers
and settle on the gate count. I see thousands of gates being thrown left and
right and since the net result does not point to the same direction, I am
not sure whom to trust any more (and I am sure others feel similarly). I am
however quite curious how you arrived to your gate estimates and memory
sizes. Perhaps it is something to be taken offline. They do look very
optimistic to me.
And please note, that the 20% trade off you're building the case is
something I do not believe in in real-world scenario. It had a lot of
assumption in it and once you put multicast and broadcast traffic on top of
the network, your 20% benefit will be gone. Please talk to Eugene about it,
he showed a few models at the last meeting which demonstrated how from a
gain you can quickly end up losing bandwidth.
Marek
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Tuesday, January 08, 2013 22:46
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc
and plan for 1/4/13 MMP Ad-hoc
Marek,
I totally agree with you that we need to consider the 5 critters and not
just "wish lists". So let's consider how complex and costly the solution
proposed by QCM in SA is.
The Channel Bonding Sub-layer is not much more that a small demux, perhaps
200 gates and a control memory of 3-4 bits x 2k entries (2 bits x 8 entries
for a CNU that supports two profiles and 8 LLIDs). The Channel Combining
Sub-layer can likely be accomplished in the DSP with no additional hardware,
maybe a little software. The 3-4 lane PHY (1 per profile in the CLT) would
likely be implemented by time slicing a single PHY, so let swag an
additional 15-20% gate count increase over a single lane PHY (my guess based
on past design experience is that this is probably conservative). Assume a
PHY gate count of 150,000 Gates (based on my knowledge of a GPON PHY I
worked with in a past life). So let's say the PNY cost/complexity increases
by 20% (again conservative).
How much of the sellable unit cost/complexity is accounted for by the PHY?
The last time I worked with a major IC vendor on a similar project the ONU
chip with its many bells & whistles came in around 3 Mgates (of which the
150k were PHY) so lets say the PHY accounts for 5% of the silicon. This mean
the 20% cost/complexity increase at the PHY translates into a 1%
cost/complexity increase at the unit silicon level. Then of course you need
to consider mechanics, PCB, and any other functions the unit incorporates.
So assume this silicon accounts for 30% of the unit cost (VERY conservative
imho). The overall unit cost has increased maybe 0.3%
Weight this against a performance increase of at least 20% as has been shown
in a number of presentations and I think the trade-off is warranted.
I say this wish belongs on the list of features.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Tuesday, January 08, 2013 3:33 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Ron,
You just can't take a decision whether to add such a feature into the
standard or not on a flip of a coin, disregarding the impact analysis. Such
a decision has impact on complexity, cost, performance as well as technical
and economic feasibility of the resulting system. This is what we are trying
right now to assess, to make sure we do not take the wrong decision. So I
respectfully disagree that our mission is not to worry on how it is
implemented - in fact, if decided in favour, we would need to write the
standard which describes implementation of such a feature using the 802.3
model. Furthermore, we do need to worry about the resulting cost, especially
in the light of Economic Feasibility criteria our final product has to meet
- we have a contract with 802 as the whole to make it cost-effective.
Regards
Marek
From: Ron Wolfe [mailto:rwolfe@xxxxxxxxxx]
Sent: Tuesday, January 08, 2013 00:35
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
To me it feels as though we may be having a discussion beyond the scope of
the group.
With the exception that it is focused not just on unicast, but also on
multicast and broadcast, I view this as very similar to adaptive streaming
in the MPEG transport and IPTV domain. I am not implying the technology is
necessarily the same, but rather that those use cases that drive the need
for adaptive streaming in the video domain will drive it in the EPOC domain
as well. HFC is not like FTTx, and downstream is not like upstream.
Downhill from the FCU there will be many things that will affect the
throughput of the system; some widespread and some isolated, and to force
all clients to a lowest common denominator is (in my opinion) likely to
result in a less than ideal solution.
Yes, it is true that there is some embedded cost that will exist whether or
not (and how) the MSO utilizes MMP, but if I recall, our mission was not to
resolve how this is implemented, nor how much it costs, nor to what extent
it would be utilized, but instead to decide as a group whether it should be
incorporated into the standard.
Am I over-simplifying?
Ron
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, January 07, 2013 5:14 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Marek,
Actually, I believe you suggested the idea of multiple EPoC generations to
support MMP; or at least that's the way I understood your previous email
where you suggested that we could introduce MMP to FDD operation at a later
date. So I was trying to respond to that by indicating that in the case of
MMP, because of the assumptions that get built into the system without at
least creating the framework to support it, introduction at a later date
most likely would not be possible.
Additionally, it doesn't necessarily have to be multiple generations, but
rather an optional feature that vendors could choose to implement or not
based on their perceived market need.
And for what it's worth, I like the idea of having just one generation - it
makes operations a lot simpler. My personal experience to date, though, has
been that if you try to throw everything into the first generation the cost
is too high; and that has forced us to design in the ability to support
multiple generations. It'd be great if that weren't the case here; believe
it or not, I'm trying not to make any assumptions on that point in either
direction, and to get a sense of where the best cost/complexity/feature
balance might be for EPoC.
Anyway, just some thoughts.
Thanks.
Matt
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Date: Monday, January 7, 2013 5:00 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>,
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Matt,
I do not think that helps much. Configuration messages, even though
important from the management perspective, are just a minor aspect of the
PHY operation. It like selecting the types of locks in your house and
concluding that the most critical part of the building process is done.
As for the topic of understanding MMP from day one - you're assuming
immediately that there will be multiple generations of equipment, that they
will have to coexist and that we have to specify everything under this
project. I disagree with that assumption. I think if we do the job well,
we'll need no generations at all. I certainly would not like to see EPoC
being burdened with DOCSIS-like complexity from day one. We have a chance to
design a system that perhaps is not as loaded with options and perhaps does
not achieve 100% of spectral efficiency, but should be simple and
cost-effective.
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, January 07, 2013 23:48
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Marek,
I guess I was thinking more that perhaps the feature exists, but there isn't
a requirement to use it (or to even be able to use it). So for example, you
would define the message framing and the signaling that would allow multiple
profiles to operate, but you wouldn't require devices to support more than
one profile. It's a bit more development work that might've been necessary,
but not necessarily a lot depending on how things are define. This assumes
that the bulk of the implementation complexity comes when you move from a
single profile to more than one; an approach like this would allow you to go
there in the future, but wouldn't require you to do so. That said, it only
makes sense if creating the framework doesn't cause a big hit in complexity.
As for why FDD devices would have to understand it. The problem is that if
you define the CNU such that it always expects a continuous downstream, and
more importantly that it can receive any signal in the downstream, then it
is all but impossible to introduce the idea of not receiving everything in
the downstream subsequently, as you would have to replace every CNU on the
network to get it to work (and that just isn't practical). Instead, you
need the CNU to understand - from day 1 - that it might not be able to
receive everything on the downstream. It might not be able to change
profiles, but it would understand enough to be able to ignore other profiles
without having issues.
Does that help at all?
Thanks.
Matt
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Date: Monday, January 7, 2013 2:53 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>,
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Matt,
I do not think we can "lay down the framework" like that in 802.3. Either
the feature exists or it does not, especially when we're talking about
features which will have to be hardware implemented.
Also, I am not sure why FDD devices have to understand it. It is not that
TDD and FDD devices would have to inter-operate on the same network. I hope
you're not assuming that .
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, January 07, 2013 21:51
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Marek,
I agree that they are intertwined - apologies if that was not clear from my
email, because I definitely agree that technical feasibility and complexity
directly play into the economic question.
The problem with not including MMP into the FDD design from the beginning is
that this is the sort of feature that, even if devices don't support it,
they have to at least understand it enough to not be confused when it shows
up (IMHO, at least). Something like this is likely going to need to be a
part of the framework of how things are framed and put on the wire; as such,
it may simply not be possible to add it in later unless the framework is
already in place.
While might be another way of approaching this. Perhaps it would make sense
to put the basic framework in place to support MMP, but not require it to be
implemented. In that way, you lay the groundwork so that it could be
implemented in the future, but you eliminate 95% of the complexity for the
first go-around.
Of course, there is a question of whether or not you really can eliminate
95% of the complexity in that case; and ultimately that will revolve around
what that framework looks like.
Thoughts?
Thanks!
Matt
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Date: Monday, January 7, 2013 2:38 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>,
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Matt,
For me, economic feasibility and technical feasibility are interleaved.
There is no economic feasibility for complex solutions, requiring large
chipsets, tons of power and even more buffering. What we need to strive is
simple solutions, not solutions at any cost. There is a reason why Ethernet
is the leading technology for layer 2 transport and that reason is its
simplicity, robustness and cost effectiveness.
That said, I do not think any new arguments were brought in favour of MMP or
can be brought against MMP. We are repeating discussions that already took
place at least twice, wasting time that could be used in a more constructive
fashion. This leaves us where we were at the end of last meeting. Perhaps an
alternative option for going forward is then incorporating the MMP design
into TDD mode first, working out the details and adding it to FDD when it is
ready later on. Otherwise, I do not see how we will move forward here.
Regards
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, January 07, 2013 21:19
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Eugene,
Thanks for the note, which is useful both for getting all thoughts on the
table and ensure we're thinking of the same thing when we refer to this
feature.
For example, while I would agree with you that there is no direct
correlation between MMP and SLA, and that end-users would likely not get a
higher provisioned tier of service as a result of this feature, might it be
possible that they would see some benefit at congested times because there's
more bandwidth to share around?
Also, you mentioned in your email that service providers do not have direct
control of the feature, and I'm curious what specifically you're thinking of
in that case. My assumption has been that while we would not want to
preclude the ability for a CLT/FCU to make autonomous changes to a profile,
it would be something that was both not required and configurable by the
operator. In that sense, the operator has full control over what profiles
are available. Further, while we'll certainly want to have some autonomous
mechanisms for switching between profiles - and we'll need to defer to the
CLT to decide how to schedule things, at least to some degree - I don't
think it would be unreasonable (and likely in fact a very good idea) to
allow the operator to define a progression order for the profiles (if you
have to leave one profile, then you go to this other one next, etc.), and
maybe even some high level bounds around when to switch (again, allowing
room for vendors to develop their own algorithms). In those ways, I was
thinking that the operator would have a large degree of control, which they
could choose to use or not. Did you have something else in mind?
As for economic feasibility, that will be driven by a combination of the
potential economic gain from the feature vs. its cost. The former is very
much derived from analysis of use cases (IMHO), which is why I think they do
have relevance; the latter is driven by technical feasibility and
complexity.
What I would be very interested in seeing is more details on why people
believe it is not technically feasible to do MMP with EPoC. I'm not saying
that it is or it isn't - I don't regard myself as enough of an expert on
EPON to render an opinion there. However, when I hear one group say it is
feasible, and another say it isn't, that makes me want to understand better
why one side or the other thinks it is or isn't feasible. Does that make
sense?
Thanks!
Matt
From: <Dai>, "Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx>
Reply-To: "Dai, Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx>
Date: Monday, January 7, 2013 1:34 PM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Jorge:
Sorry for missing the last meetings, I was at Pacific Time zone. Now I am
back to East time zone, I'll try to join tomorrow's meeting.
The fundamental question of MMP is its technical and economic feasibility
under the EPON MAC framework; I didn't think use cases will help at this
point. We have presented detailed analysis of both technical and economic
challenges of MMP at the San Antonio meeting; I believe everything we have
presented still hold. Although I do not believe re-present the old material
will help moving forward, I am willing re-present the main points (of San
Antonio presentation) tomorrow if necessary; it seems this was what other
people did anyway.
A few summary points:
From service providing point of view:
. End-users do not get notable benefit from MMP
. Service providers do not have direct control of MMP
. There is no direct relationship between MMP and SLA
From technical feasibility point of view:
MMP introduce significant complexity at PHY, MAC and system levels,
especially for EPON to coax rate adaption.
From outside plant point of view:
A network reference model is needed that including outside plant and
in-home-networks that provide base outside plant conditions reference for
the future EPoC.
Thanks,
Eugene
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Monday, January 07, 2013 2:51 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Ed,
Perhaps, given that you're having difficulty getting to the ad hoc calls,
you could enumerate your issues here on the exploder. That would at least
open the dialog and we could debate the issues you see. Personally I don't
see anything that cannot be addressed.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Monday, January 07, 2013 2:29 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Hi Jorge,
I hope that you had a great holiday. Sorry but I'm a little behind on
things due to the time off.
I agree with Marek. I presented issues with the MMP at the last meeting. I
looked over the Qualcomm presentation from the Ad Hoc and I didn't see any
difference from the last IEEE meeting. The issues that I raised at the
meeting still exist. If you like, I can repeat those issues to the Ad Hoc.
As we discussed before, I'm not able to attend the Ad Hoc based on the time
selected. I can try to call in from 6am to 7am on tomorrow's call.
Take care,
Ed.
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Friday, January 04, 2013 4:47 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for
1/4/13 MMP Ad-hoc
Jorge,
I was under the impression that presentations on the topic of technical
challenges associated with MMP implementation have been already presented
and discussed in detail at the meetings. I am not sure how presenting the
same material in a new form helps move us forward in any way.
Perhaps a list of questions on specific aspects of already presented
technical challenges would be a better way to move forward? That would give
time to prepare concise and comprehensive answers to the benefit of this
ad-hoc. I fear that we if we start discussion on the phone, we'll get lost
in details again.
Regards
Marek
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Friday, January 04, 2013 05:46
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13
MMP Ad-hoc
Folks,
Thanks to those that were able to attend the meeting yesterday. We did not
have any presentations on why MMP could not be implemented, so we took the
opportunity to review the diagram outlining the use case we reviewed before
the holidays (see below for reference). We had lots of discussion about this
use case, but did not arrive to any specific conclusions. I attached a
transcript of the discussion that Joe Solomon kindly recorded.
Given the discussion, and to help the continuation of this discussion, I
expanded the use case into 4 slides, each progressively more complex. We
will review these slides during our meeting tomorrow.
HOWEVER, our focus is on determining why and/or how is MMP not possible to
implement. To that end, we are seeking presentations that would outline that
specific topic. So, if there are any presentations that address why and/or
how MMP can not be implemented we will give those presentations the
priority.
Thanks!
Jorge
_____
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
_____
_____
_____
_____
_____
<="" p="">
_____
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
