Re: [802.3_EPOC] Why multiple simultaneous MCS
Another place to look at is, for example, 802.11. Just trying to encourage
folks to see that Ethernet can accommodate some complex phys when there is
layering other than just MAC/PHY (OSI). I don't think the MAC has to handle
physical link layer negotiations and channel management.
-Victor
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Wednesday, October 10, 2012 8:11 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Hi Duane,
I will add that we rejected many more features and ideas than we took in
EFM. As I recall, Broadcom proposed the DOCSIS MAC for EPON with a ton of
features that got rejected. J There was also a SONET framing with fast path
and efficient path. I don't agree that we resolved the academic issues with
the MAC and layering restrictions. We simplified the specification and
removed functionality until the changes worked with the Ethernet MAC and
upper layers. The REPORT and GATE frame are clear examples of compromise.
There are more efficient solutions but we had to go with simpler. As an
ASIC designer, I'm really glad that the REPORT status is so simple. It is
very fast and we are able to perform the scheduling in hardware because of
it. EPON came to market quickly because we kept it simple. The
specification time was short because we leveraged the existing standards.
I'm not as confident as you are that we can get past the standard
limitations.
Just like the idea of the adding DOCSIS channel bonding to EPoC, it is not
whether it is possible but whether it is a reasonable amount of complexity,
time to specify, and challenge to interoperate. Is the complexity worth the
reward? I can point to many features in DOCSIS that would increase the
efficiency of EPoC. The payload header suppression, ACK suppression,
removal of Ethernet IPG, MAP for many LLIDS instead of GATE for each LLID,
fragmentation, not using full frames for REPORTs, 2-diminesional upstream
scheduling, tighter clocking, shortened FEC codewords, multiple FECs for
different burst sizes, etc. These are clear ways to increase the efficiency
of the upstream and/or downstream. I think that EPON and Ethernet were
successful because it wasn't complex and I don't think that we need to adopt
all of the functions of DOCSIS to be successful. DOCSIS will efficiently
use a limited amount of spectrum. I detailed the complexity of the MCS
feature in a previous email and I don't like my answer. Please prove to me
that isn't true. I think that it adds lots of delay, gates, and new
specifications.
From my point of view, the complexity added could easily be the difference
between offering a 2.5 Gbps downstream device and a 5 Gbps downstream
device. I would like to follow the other Ethernet devices with higher
speed, lower delay, and lower cost. I think that EPoC downstream will give
cable a big efficiency improvement by being a single wide IP pipe with low
latency. The EPoC upstream will be more efficient with a faster downstream.
I promise to not send another email like this one. I would rather respond
to the specifics on what is required for multiple downstream profiles. I
put together slides on what I think is required to implement this feature.
I can present at one of the existing calls if requested. (I won't be
responsible for more conference calls).
Take care,
Ed..
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, October 10, 2012 1:10 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Marek,
During EFM we ran into the same concerns over the Ethernet MAC and layering
concerns. We were able to resolve those issues and I have confident that, if
we need multiple profiles (which may be the case) that we will be able to
resolve these, somewhat academic, issues again.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Wednesday, October 10, 2012 3:51 PM
To: Duane Remein; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Duane,
Very much true. Drawing conclusions on what should or should not be
supported right now is futile. We do not have a way to weigh them in in any
measurable way right now, apart from acting on a hunch. Apart from the link
model itself, I am concerned, similarly to what Eugene and others expressed,
about the impact that it will have on the 802.3 layering model and
implementation later on. Everything works nice on paper, but you know
yourself well that only when you get to actual details, problems emerge.
Marek
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, October 10, 2012 15:39
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Marek,
One thing that we didn't have to contend with when "we have typically
designed specs before" was that the network was already buried in the ground
at great expense to our customers. Sure 10G-EPON had to concern itself with
already deployed plant but that was defined in 2002 or so, only recently
deployed and, being optical, is much more benign than COAX.
I think much of the drivers for the conclusion that Matt is expressing will
and should come from the channel model we end up with. That will determine
the level of complexity we need to meet our objectives ("A baseline data
rate of 1 Gb/s at the MAC/PLS service interface ." among others).
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: Wednesday, October 10, 2012 3:01 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Matt,
It would be nice if the discussion also involved these "others" you
reference. It seems that you're building a case for pre-existing consensus
on this topic, yet this is not what we observed at the last meeting in
Geneva. I would encourage these "others" to voice their opinions rather than
rely on the group representation.
Now, for technicalities.
Your argument on SNR headroom is valid enough for consideration. However,
the way we have typically designed specs before was on putting also some
requirements on the cable plant and not only on the equipment. It seems to
me that you're building the case under which the cableplant can be as bad or
good as it is, while the equipment has to have all the required flexibility
to adapt to any plant (physical link) that it has to operate on (and
conversely, take the hit in terms of complexity and resulting cost). While
it is fine if that is what the group wants, before we take the plunge into
development, I think it would be worthwhile if yourself and the unnamed
"others" presented a detailed analysis of the added cost, impact on latency
and something more of a detailed study of how such MCS function could be
implemented in EPoC without moving away from EPON-like protocol. I
understand that there may be growing consensus on the side of DOCSIS 3.1
that it needs to be done, but without such a study, I personally will not be
able to make an educated vote on this matter. Seeing how you propose this to
be done in 802.3 architecture would make all the difference for me.
I voiced my concerns before and I hope solution exists to them in a way that
makes us move forward. Appealing as the MCS might be, it needs to go through
the proper technical scrutiny, involving looking at the cost / performance /
latency / implementation issues. Only then I believe we can take a decision,
and not before.
Regards
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Tuesday, October 09, 2012 23:25
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPOC] Why multiple simultaneous MCS
Based on some of the discussions, I think it might be worthwhile to spend a
moment going into the chain of reasoning that led myself (and others) to the
conclusion that an advanced next generation HSD system for HFC (such as
EPoC) should include the ability to support multiple simultaneous Modulation
and Coding Schemes (MCS).
If I were to sum it up in 2 words (okay, technically 4), it would be this:
SNR Headroom.
In a system that requires all end stations to operate with the same MCS (and
to receive all downstream transmissions), the great danger is that for
whatever reason the SNR to a given end station will change sufficiently that
it will drop offline. That simply cannot be allowed to happen. As a
result, operators are required to maintain a significant amount of "SNR
Headroom" when they setup and deploy an end station. Common practice is to
allow on order of 8 db of SNR headroom when deploying a modem (some a little
more, but I'm not aware of any that do less).
What this means is the following. Let's say that you needed 25 dB of SNR to
operate 1024 QAM with a 3/4 LDPC FEC code (which I believe is the case with
DVB-C2, and serves as a useful reference point here). An MSO would not
actually use that MCS unless they could get their end stations at 33 dB of
SNR (25+8) when deploying them. If they couldn't get to that level when
deploying the end station, they wouldn't be able to use that MCS.
I pulled out that particular number because, based on the SNR distributions
that were shared previously, even if you assumed you could "bring up" the
bottom 2.1% of modems, that's the best you could expect to do. And even if
you could further improve SNR, you're still always going to be operating in
effect 8 dB below what you could theoretically do. For example, just to get
to 4096 QAM with a 5/6 LDPC FEC, you'd need to get every single end station
to operate at about 40dB or higher of SNR.
Now, if you could get away from requiring that 8 dB of headroom, it would be
huge, considering that 6 dB is an order of modulation with the same FEC, an
increase of 2 bits per symbol.
One way to achieve that end is to support multiple MCSs, but only one at a
time, which is set based on the "lowest common denominator". In this
approach, if an end station were to have a sudden drop in SNR, then the
system would need to drop to a lower "lowest common denominator", until such
time as the problem could be addressed. By having that fall back, you could
in theory operate closer to the theoretical maximum and reduce the amount of
headroom required.
However, there are some issues here. First, one bad end station coming onto
the network - or a single problem in a single household - would affect the
entire network, degrading the service of every single end station. Second,
particularly in the scenario where an end station encounters a problem after
it's already online, there's no guarantee that it would even still be able
to communicate that it was having a problem and that it needed the MCS to be
changed. That risk is then going to force you to leave more headroom,
mitigating any potential gains.
The only approach that we've come up with so far that allows you to
significantly reduce that headroom and operate close to theoretical levels -
while not adversely affecting the entire system when there's a problem - is
to create a system in which a single end station is able to fall back to a
more robust MCS if it encounters a problem. In that way, only the single
device having an issue is affected, and unless the problem is truly
catastrophic you can reliably keep the mode online (meaning that you have an
opportunity to fix the problem while the customer remains online and
operational).
We could argue back and forth for quite a while about SNR spreads on the
network, how much variation there will be between end stations in a given
service group, etc. And the ability to operate each device to its maximum
potential is very appealing to be sure. But what really makes this
decision, in my opinion, is the SNR headroom issue, and in particular the
ability to significantly reduce it while actually improving robustness and
the ability to keep customers on line.
Thanks.
Matt
_____
_____
<="" 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