Two points I'd like to make:
1) it is very important to list at least one other application besides
tunneling that relies on fragmentation. Frankly, unless the list is
prohibitively long, it should absolutely be included to help avoid this
document laying the foundation for future arguments to deprecate
fragmentation "except for tunnels". Iperf is more than just a test
application; it speaks to the issue of network monitoring using active
injection using that tool, so it's more than 'just a test application'.
2) The statistics below assume independent drop probabilities. A smarter
way to handle fragment drops was realized in the ATM/AAL5 days, i.e.,
when you drop a fragment at a queue, then drop all other associated
fragments (if possible, if nearby, etc.). Note that tail drop would
already potentially do this at least partly and other drop mechanisms
might be extended to have similar properties without actually scanning
the queue.
Joe
On 2018-10-15 08:32, Tom Herbert wrote:
> On Mon, Oct 15, 2018, 8:14 AM Ron Bonica <[email protected]> wrote:
>
>> Hi Fred,
>>
>> Thanks for reviewing yet another version of the draft. But I would like to
>> push back ever-so-gently on your proposed edit.
>>
>> We agree that the draft does not and should not propose the deprecation of
>> IP Fragmentation. We also agree that IP tunnels require fragmentation. And
>> because one critical application requires fragmentation, we cannot deprecate
>> it.
>>
>> Yes, there may be other applications that require fragmentation. IPERF may
>> be one of them. But we don't need to mention it because we have already made
>> our case against deprecation. Mentioning every application that requires
>> fragmentation is over-kill.
>
> Iperf is just a test application so it shouldn't be mentioned here anyway. It
> does illustrate another problem of fragmentation. That is if just one
> fragment of a packet is lost then the whole packet is lost. So with a 1% drop
> rate, a packet with two fragments has a drop rate of 2%, 10 fragments has
> drop rate of 10% 64K packet makes 43 fragments of 1500 bytes so drop rate of
> those packets is 35%.
>
> I believe this amplified drop rate is a problem inherent of fragmentation and
> good reason why not to use fragmentation over the Internet. This probably
> should be mentioned in the draft..
>
> Tom
>
>> Ron
>>
>>> Message: 2
>>> Date: Wed, 10 Oct 2018 16:22:47 +0000
>>> From: "Templin (US), Fred L" <[email protected]>
>>> To: "[email protected]" <[email protected]>
>>> Subject: Re: [Int-area] I-D Action:
>>> draft-ietf-intarea-frag-fragile-01.txt
>>> Message-ID:
>>> <554d668a29934ecf9fdf95d77d1cca52@XCH15-06-
>>> 08.nw.nos.boeing.com [1]>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> I made this comment earlier, but it does not appear to have made it into
>>> this
>>> version.
>>> Some applications invoke IP fragmentation as a performance optimization,
>>> and that should be mentioned here. But, it also needs to say that RFC4963
>>> warns against reassembly errors at high data rates.
>>>
>>> Suggestion is to add the following to the introduction:
>>>
>>> "While this document identifies issues associated with IP
>>> fragmentation, it does not recommend deprecation. Some applications
>>> (e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Others (e.g.,
>>> [IPERF3]) invoke IP fragmentation as a performance optimization, but
>>> can incur reassembly errors at high data rates [RFC4963]."
>>>
>>> Thanks - Fred
>>> [email protected]
>>>
>> *************************************
>>
>> _______________________________________________
>> Int-area mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
Links:
------
[1] http://08.nw.nos.boeing.com
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
