On 6/2/2016 7:53 PM, Xuxiaohu wrote: > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Friday, June 03, 2016 2:08 AM >> To: [email protected]; Xuxiaohu >> Cc: Softwires WG; [email protected]; [email protected]; [email protected]; >> [email protected] >> Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation on >> UDP >> encapsulated packets. >> >> >> >> On 5/27/2016 3:50 AM, [email protected] wrote: >>> It is not possible to implement reassembly complying with IETF RFCs. >> a) ATM does this at ridiculously high fragment rates. Granted IP frags can >> come >> out of order, but the fragments are generally much larger. > As pointed in RFC4459, > > "At the time of reassembly, all the information (i.e., all the > fragments) is normally not available; when the first fragment > arrives to be reassembled, a buffer of the maximum possible size > may have to be allocated because the total length of the > reassembled datagram is not known at that time. Furthermore, as > fragments might get lost, or be reordered or delayed, the > reassembly engine has to wait with the partial packet for some > time (e.g., 60 seconds [9]). When this would have to be done at > the line rate, with, for example 10 Gbit/s speed, the length of > the buffers that reassembly might require would be prohibitive. "
Yes, but the alternative of declaring that you don't reassemble has a cost in terms of dropped segments too. Taking that drop into account, buffering for a smaller amount of potential reordering and accounting for reasonable reassembly sizes (for IPv6, the smallest "max" that's required is 1500) need not be prohibitive. > Have you heard the wide adoption of 622M (STM-1) beyond ATM interfaces > between ATM switches in the previous ATM networks? If not, the highest > non-ATM interface in the past ATM networks was the FE interface which is 100M > bps (around the year of 2000), If I remembered it correctly. OC12 ATM NICs were commonly available in 1998. That was back when ethernet was pushing 100M and the only other near-gigabit tech was Myricom (a spin-off of USC/ISI and Caltech). I.e., with the tech available at that time, 600Mbps SAR was possible. > Furthermore, have you heard the reordering issue with ATM cells? If no, that > means once an ATM cell of a given ALL PDU gets lost, all the received ATM > cells of that AAL PDU would be dropped and therefore the reassembly buffer > for that AAL datagram would be released. In other words, there is no need to > wait for the lost or reordered fragment for a certain period of time before > releasing the reassembly buffer. Reordered no, but just because they arrive in order does not mean they are required to arrive *adjacent*. The same requirement applies in terms of needing reassembly buffers for a number of interleaved segments. > Such behavior is not possible for IP fragmentation and reassembly. Last but > not least, there is no need to assign a reassembly buffer per AAL PDU (as > opposed to per IP datagram in the IP fragmentation and reassembly case), > instead, only one reassembly buffer per VC since all cells within a given VC > would be received in order. Since the SAR is only needed on the edge of the > ATM networks, the number of VCs is very limited. You could easily decide to allocate a fixed number of reassembly buffers per IP flow to conserve resources too. The amount of reordering, together with the number of flows supported would determine your ability to avoid packet drops -- but recall that drops at high load are not unusual for IP. Joe _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
