On Mon, Oct 15, 2018 at 11:00 AM, Joe Touch <[email protected]> wrote: > > > > > 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. > Why is that clear? Of course when dropping a fragment then it makes to drop all related fragments of the train. But there's no guarantee that the node even sees any of the other fragments. Something like RED might help with locality of fragments arriving is true, but only offers heuristics to mitigate the problem.
> 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. Dropping at oversubscribed queue isn't the only source of drops, a lossy radio link could produce uncorrelated losses for instance. Besides that, if you want to consider correlated drops then the math is very different. For instance, suppose someone sends 10 TCP segments which could alternatively be sent as one TCP segment and 10 fragments. Now suppose last 5 packets are dropped in each case. Goodput in TCP is 5 packets worth of data, goodput in fragmentation is zero. > > 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. It would be interesting to see the reall world case where fragmentation can do better or as good (either in goodput or performance), but I'm doubtful that exists. > > Joe > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
