Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Monday, October 15, 2018 11:52 AM > To: Templin (US), Fred L <[email protected]> > Cc: Joe Touch <[email protected]>; Ronald Bonica <[email protected]>; > int-area <[email protected]> > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt > > On Mon, Oct 15, 2018 at 11:41 AM, Templin (US), Fred L > <[email protected]> wrote: > >> 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. > > > > One of the applications I am referring to works over space links where there > > are long delays, but no congestion and hence little/no IP packet/fragment > > loss. > > This is a case of a long, fat network (LFN) and because there is > > significant delay > > (reliable) UDP is used instead of TCP. > > Okay, that could be one use case. But then I have to ask: why not just > crank up MTUs to a high number to eliminate fragmentation overhead?
It is a good question, but it is not always possible to lay hands on the media to set a larger MTU. And some link types (e.g., legacy Ethernet) don't support larger MTUs anyway. Of course, modern Ethernet with 9K jumbos can do more but some applications may want to push the UDP datagram size all the way to 64K. >From what I saw when I was working with iperf3. By default, it uses 8KB UDP datagram sizes when it runs on Ubuntu. By setting the UDP datagram size to a smaller value (i.e., one that needs less IP fragmentation) it shows a performance decrease. By setting the UDP datagram size to a larger value (i.e., one that needs more IP fragmentation) it shows a performance increase. Fred > Tom > > > > > Thanks - Fred _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
