Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Adding to Avi’s comment, at or near congestion is exactly when the additional bandwidth due to higher bandwidth efficiency is useful.
Victor
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Wednesday, January 29, 2014 11:16 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Marek,
Wouldn’t an additional 7% available bandwidth move this point of congestion 7% higher in rate?
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Thursday, January 30, 2014 5:09 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Duane,
All these gains will work just fine when they are least needed, i.e., when CLT can grant exactly as much bandwidth as requested by the CNU. It is not clear to me, even from Rich’s presentation at the last meeting, what really happens when CLT grants less bandwidth than CNU requested (upstream is congested). The CLT does not have enough information to grant exactly on frame boundries and statistically it is quite unlikely that CNU will be able to fill in the granted slot precisely. At this time, it becomes unclear whether the stated packing efficiency gains give us anything when the channel efficiency really matters.
I think it would be an interesting study for the next meeting.
Regards
Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, January 29, 2014 8:13 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
John,
I think you’re making a very valid point here; why toss out the LDPC coding gains to simplify with a single FEC. Plus I’ll again make the point I did on the call; at the data capacities we’ll be seeing (at least initially) due to spectrum availability I think the extra 7-10% or so will be welcome.
Personally, having looked at the differences to do two FECs vs three FECs at the MAC level I don’t see a significant increase in complexity there. Once you’ve gone to more than one you’ve taken on the Lion’s share of the complexity to go to three.
It would be really good to see the burst size distribution to see how often we’d be tossing another 5-10% efficiency gain in the mid sized burst range but it doesn’t appear we’re going to get that data.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC
From: Ulm, John [mailto:John.Ulm@xxxxxxxxxx]
Sent: Wednesday, January 29, 2014 6:17 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Sorry I missed the call today, but have a standing conflict at that time.
I think Rich makes an interesting analogy with the Task Force choosing LDPC over much simpler and less effective FEC. That LDPC choice effectively gave us an additional 3dB on the HFC which means the difference between operating at 4096-QAM modulation instead of 2048-QAM (which happens to be ~8-9% improvement). It doesn’t make sense to me to throw away that 3dB gain for the sake of un-quantified simplification for a Med only codeword.
Ed’s presentation does seem to make a case for L-S over L-M-S.
-- john
From: Rich Prodan [mailto:rprodan@xxxxxxxxxxxx]
Sent: Wednesday, January 29, 2014 12:58 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Marek,
As you note, there exist disparate arguments on this topic, some of which are unsubstantiated. I believe that removing the hand-waving unsubstantiated points (“opinions”) with facts will be educational and resolve the need for “believing”.
Rich
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Wednesday, January 29, 2014 10:46 AM
To: Rich Prodan
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
Rich,
I do not believe anybody argues against the use of LDPC codes, so we can put that avenue to rest. What I am arguing is that I hear contradictory arguments being made, and not being able to test each and every possibility myself, I have a hard time believing either side of the argument: one says it is black, another one says it is white. It is very hard to build an educated opinion on this topic where such disparate opinions are voiced. The logical solution would be for all people who understand FEC to get together and work out differences and present a single agreed proposal. Otherwise, it is hard to expect that all TF members become experts in this area overnight and be able to argue one way or another.
Marek
On 29 January 2014 12:30, Rich Prodan <rprodan@xxxxxxxxxxxx<mailto:rprodan@xxxxxxxxxxxx>> wrote:
All-
If simple algebra is too complicated for your understanding of optimizing efficiency, then perhaps understanding these simple algebraic relationships for multiple codeword sizes and their respective thresholds that minimize the total number of parity bits in a burst is the key. It is not rocket science, nor even information theory and belief propagation, which the latter is required to understand the utility of LDPC codes (which I assume nobody wants to replace with RS or BCH block codes which are much simpler but less efficient algebraic codes).
Furthermore, the hardware to decode multiple sizes of the current upstream quasi-cyclic LDPC codes is about the same as the single longest such LDPC code.
Additional encoding/decoding delay is similarly negligibly different unless we place the coded bitstream directly on the transmission medium like EPON. EPoC requires a 1D to 2D mapping of the entire coded bitstream in the burst onto OFDMA resource blocks (or all resource blocks if allocated the entire symbol for a long burst). Only then can the inverse FFT be performed and the resulting waveform be transmitted in the appropriate frequency band.
I believe that this understanding can be achieved so that 7% to 15% of efficiency is not wasted for NO substantial decrease in cost or hardware complexity.
Rich
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx<mailto:marek.hajduczenia@xxxxxxxxx>]
Sent: Wednesday, January 29, 2014 10:05 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Any presentations for Wednesday's scheduled PHY Sub-Group Conference Call?
I would rather to work off a simple scenario and try to figure out whether it is acceptable, rather than try to simplify something unnecessarily complex
Just an opinion, nothing more. And as always, I believe my take on your presentation after it is given live will be different than when I read it myself ;)
Marek
On 29 January 2014 11:50, Ed Boyd <ed_boyd@xxxxxxxxx<mailto:ed_boyd@xxxxxxxxx>> wrote:
Marek,
I agree that it is far too complicated. I want to remove some of the complications. I compared the simplest method of a single medium shortened to what has been approved so far. At a minimum, we can remove complexity that has negative or little performance improvement. Of course, we could decide to go with the simplest approach. I'm trying to clearly identify the difference on each option.
Thanks
Ed
Sent from my iPad
On Jan 29, 2014, at 7:12 AM, Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx<mailto:marek.hajduczenia@xxxxxxxxx>> wrote:
Ed,
In all honesty, I look at your presentation and I am getting really lost in all options and conclusions being drawn. Is it just me, or we are just overdoing it on the side of options and optimizations? What's wrong with picking just medium FEC codeword and allowing for codeword truncation at the end? The decoding process should be fairly easy, since it would be driven by either full FEC codeword or end of burst marker sequence. It does not seem to affect negatively SNR and decoder latency and at the same time we avoid all the complexity of options, filling algorithms and assumptions that the CLT has to make to calculate the size of the grant to accommodate reported data.
I feel that we are driven to decide based only on the very noble, but yet completely impractical notion of very high efficiency. Ethernet has been always about low cost and robustness and not perfect efficiency. I understand the need to use the spectrum resource efficiently, but after a certain efficiency point, cramming more bits into the channel incrementally increases the overall system cost, its complexity and decreases its robustness.
My suggestion is therefore simple: pick medium FEC codeword we have defined right now, allow for codeword truncation and move on.
Regards
Marek
On 28 January 2014 17:51, Ed Boyd <ed_boyd@xxxxxxxxx<mailto:ed_boyd@xxxxxxxxx>> wrote:
Hi Mark,
I would like to discuss the attached presentation and get feedback tomorrow if possible. I tried to expand on the comments from the FEC filling algorithm discussion at the meeting.
Thanks,
Ed…
Sent from Windows Mail
From: Mark Laubach<mailto:laubach@xxxxxxxxxxxx>
Sent: Monday, January 27, 2014 4:19 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Dear IEEE P802.3bn Task Force Participants,
Our scheduled PHY sub-group conference call is this Wednesday at 10AM Pacific.
If you have any presentations for socialization or other topics, please send them on the reflector by 5PM Pacific tomorrow (Tuesday).
Please be familiar with the IEEE SA Patent Policies at:
https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf
WebEx Meeting Number: 920 271 005<tel:920%20271%20005>
To start: https://broadcom.webex.com/broadcom/j.php?J=920271005
Yours truly,
Mark Laubach, Chair
IEEE P802.3bn EPoC PHY Task Force
Broadband Communications Group
Broadcom Corporation
1351 Redwood Way
Petaluma, CA, 94954
<image001.jpg>
Tel: +1.707.792.9093
Cell: +1.650.996.2219<tel:%2B1.650.996.2219>
________________________________
________________________________
________________________________
________________________________
<="" 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