Hi Christian, > -----Original Message----- > From: Christian Huitema [mailto:[email protected]] > Sent: Thursday, November 29, 2018 3:41 PM > To: Templin (US), Fred L <[email protected]>; Fred Baker > <[email protected]> > Cc: Ron Bonica <[email protected]>; int-area <[email protected]> > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > On 11/29/2018 1:05 PM, Templin (US), Fred L wrote: > > > iperf3 is a real Internet application in the same way that ping, traceroute, > > tcpdump, etc. are real applications. It is a well-known tool that network > > engineers use on a daily basis and demonstrates that UDP performance > > is highly correlated with UDP datagram size (i.e., even for sizes that > > exceed the PMTU). > > AFAIK the main difference between large and small UDP packets is doing > the fragmentation/reassembly in the application instead of in the > kernel's UDP stack. For an 8K packet, that means 6 socket calls in the > application case, versus 1 in the kernel case. That is indeed some > overhead. It is not a big deal for medium speed application like video, > but i can see how it will get in the way of running QUIC at several > Gbps, for instance. But then, the overhead could be trivially eliminated > with API improvements, such as passing several packets in a single call.
Right, we have talked about that. A disadvantage is that the application framing headers need to be repeated in each UDP datagram, and when the application headers are large the amount of room left for actual data is diminished. Thanks - Fred > We can ponder why we have not seen such improvements yet, the main > explanation being lack of demand. I fully expect that this will change > if QUIC gets widely used. In fact, it would be good if the fragmentation > draft discussed this API issue. > > -- Christian Huitema > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
