Glen,
To make Duane’s proposal work, we will have to substantially extend the functionality of RS. Now it will have to play the role of MAC Merge from 802.3br, but not just for one MAC pair, but for each LLID and associated MAC that is instantiated in the device. This is the nature of the fragmentation and frame interruption. Furthermore, we will have to change the transmission rules within MPCP+ since now a frame should be allowed to be transmitted even if it does not fit completely into the next available upstream burst, changing some of the conditions we have had in MPCP for years. This will make burst size calculation more complex for the following burst, since MPCP+ will have to keep track of fragment size for previous burst and adjust burst size accordingly.
A once simple and straightforward MPCP will now become much more complex for the sake of half an average frame size per LLID per burst (1/2 of ~<500B average frame size, at least as far as residential is concerned).
Regards
Marek Hajduczenia, PhD, CCNP CSCO12874393
From: Glen Kramer [mailto:000006d1020766de-dmarc-request@xxxxxxxx]
Sent: Thursday, June 30, 2016 4:50 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Questions about fragmentation in EPON
Mark,
Agree, we need to focus on the problem we are solving.
Just to remind everyone (the issue was first discussed in Macao), if the ONU sends frames across all enabled (granted) lanes in FIFO order, it would be extremely easy for the OLT to recover the frame sequence (by frame start time, same as in downstream) and without any buffering at all. But the problem with this approach was that a combination of frames that gets in each grant will be different from the combination of frames that were reported by the ONU to the OLT, so every grant will be under-utilized, and a significant portion of bandwidth will be wasted (see picture on the left below). So, the proposal at that time was to pack frames in grants as they were reported (see picture on the right). That solves the grant utilization problem, but requires the OLT to buffer multiple bursts to restore frame sequence.
In Whistler, I proposed to revisit the fragmentation option so that we are not constrained by the frame delineation boundaries anymore. In this approach, the ONU will start transmitting the next frame in an earliest available grant. If that grant ends, the rest of the frame will continue in the another currently-active grant, if any. Otherwise, it will wait for the future grant. At most one frame per LLID will remain split between the OLT and ONU, while waiting for a future grant. I do not have full proposal or even a clear picture of how this would work, but Duane's proposal to do it in RS and have a signal line from MPCP to RS may help.
Glen
On Thu, Jun 30, 2016 at 1:16 PM, Mark Laubach <000006d52ee8f1bc-dmarc-request@xxxxxxxx> wrote:
Duane, all,
The motivation, as I recall, for exploring upstream fragmentation was to answer the question of does it reduce buffer memory requirements in the OLT. I would suggest if possible to focus on that question first before we get too deep into the details. If there isn’t a clear win on memory savings, then I suggest not getting into the fragmentation complexity and staying with whole packets. Perhaps select one or two “scheduling” models, then focusing on the re-assembly details in the OLT?
Mark
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Thursday, June 30, 2016 12:14 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] Questions about fragmentation in EPON
Glen/Marek,
During the call today you both expressed concerns about fragmentation. Do the following two questions adequately capture your expressed concerns? If not please clarify.
1) In a multi-lane mixed capability network (mix of 25G, 50G & 100G ONUs) how would fragmenting avoid loss of capacity due to gaps between bursts?
2) In a multi-lane mixed capability network how could fragmenting allow an ONU that is bursting on X lanes expand its transmission to X+m (ex. go from 2 lane transmission to 4 lane transmission) smoothly?
Best Regards,
Duane
FutureWei Technologies Inc.
Director, Access R&D
Raleigh, NC