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. At best it's just providing early drop to save some resources. I don't think there's any argument that fragmentation has higher goodput than equivalent unfragmented stream of packets. Tom > 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> >> > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
