On 2018-10-15 09:59, Tom Herbert wrote:
> On Mon, Oct 15, 2018 at 9:46 AM, Joe Touch <[email protected]> wrote:
>
>> 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,
>
> That doesn't improve the drop rate.
I'm proposing dropping associated fragments instead of other (new)
fragments.
This would result in the same number of bytes and packets dropped (thus
freeing up the same resources both per packet and per byte), but would
clearly reduce the number of impacted reassembled packets.
Please explain why you think this would not improve the drop rate, just
as *did* for ATM/AAL5.
> At best it's just providing early
> drop to save some resources.
Which frees those resources up for other packets/fragments...
> I don't think there's any argument that
> fragmentation has higher goodput than equivalent unfragmented stream
> of packets.
Agreed. But your math is incorrect unless drops are uncorrelated;
correlated losses could result in nearly the same impact on fragmented
packets as non fragmented packets.
Yes, it won't get better for fragments but it doesn't have to get worse,
or at least as linearly worse as you claim.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
