Re: [Softwires] [nvo3] Is it feasible to perform fragmentation on UDP encapsulated packets.

[Joe Touch <[e-mail]>]

On 6/2/2016 7:53 PM, Xuxiaohu wrote:
>
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Friday, June 03, 2016 2:08 AM
>> To: [e-mail]; Xuxiaohu
>> Cc: Softwires WG; [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP
>> encapsulated packets.
>>
>>
>>
>> On 5/27/2016 3:50 AM, [e-mail] 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