Re: [Int-area] draft-ietf-intarea-frag-fragile-03

Hi Ron,

Regarding NFSv2 [RFC1094] being obsoleted, that is why I qualified it as “Historic”.
But, I believe it is useful to include because it includes explicit text regarding
fragmentation:

    “For efficient operation over a local network, 8192 bytes of data are normally
     used. This may result in lower-level fragmentation (such as at the IP level).”

This goes to show the mindset of the 1980’s that has carried forward into the
present day with LTP and iperf3 as examples.

Regarding iperf3, I think it is informative because it shows that the concept
of the use of fragmentation for improved performance is still alive within
the present-day mindset. Also, informative references need not be RFCs;
in fact, the draft already has four non-RFC informative references that have
URLs as their location. For [IPERF3], the citation is simply: https://iperf.fr/

Can these be included?

Thanks - Fred

From: Ron Bonica [mailto:rbonica@juniper.net]
Sent: Tuesday, November 27, 2018 10:03 AM
To: Tom Herbert <tom@herbertland.com>; Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: int-area <int-area@ietf.org>; intarea-chairs@ietf.org
Subject: RE: [Int-area] draft-ietf-intarea-frag-fragile-03

Fred,

I am happy to add a section about LTP. However, I agree with Tom that we should not be talking about iPERF because:

-         It is a test utility

-         I can’t find a stable reference

Also, given that NFSv2 was obsoleted by RFC 3010 in 2000. I don’t think that it is relevant any longer.

                                                                                       Ron

From: Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>>
Sent: Tuesday, November 27, 2018 11:34 AM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>
Cc: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>; intarea-chairs@ietf.org<mailto:intarea-chairs@ietf.org>
Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03

On Wed, Nov 21, 2018, 8:47 AM Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Hi Ron,

There needs to be a new subsection in Section 6 on UDP applications that
rely on IP fragmentation for greater performance. Here is proposed text:

"Some UDP applications rely on IP fragmentation to achieve acceptable levels
of performance. These applications use UDP datagram sizes that are larger than
the path MTU so that more data can be conveyed between the application and
the kernel in a single system call.

Historically, NFS version 2 [RFC1094] set a UDP datagram size of 8KB which is
greater than the path MTU of most paths, resulting in IP fragmentation.
Currently, the Licklider Transmission Protocol [RFC5326] which is in current
use on the International Space Station (ISS) uses UDP datagram sizes larger
than the path MTU to achieve acceptable levels of performance even though
this too invokes IP fragmentation. Also, the commonly-used iperf3 [IPERF3]
performance testing utility by default sets an 8KB UDP datagram size even
though IP fragmentation is invoked since the performance of smaller UDP
datagrams is much lower.
Hi Fred,

I agree that NFS and ISS protocol are worth mentioning, but iperf shouldn't be mentioned since it is just a test program.

While it is natural to suggest that such applications should adjust their
application layer framing to better match the path MTU, such does
not always result in greater performance. For example, although the
"sendmmsg()" system call was designed to present the kernel with
multiple UDP datagrams in a single call, not all applications benefit
from its use."

The hardest part is pmtu discovery, signaling discovered pmtu to the UDP application, and then the application needs to know how to make smaller packets to fit into mtu. The last step is especially problematic since it's application specific logic. The natural recourse applications have is to just assume minimal MTU, but as you point out that can be poor performance compared to using fragmentation

Tom

Thanks - Fred

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org<mailto:int-area-bounces@ietf.org>] On Behalf Of Ron Bonica
> Sent: Wednesday, November 21, 2018 6:32 AM
> To: int-area <int-area@ietf.org<mailto:int-area@ietf.org>>; intarea-chairs@ietf.org<mailto:intarea-chairs@ietf.org>
> Subject: [Int-area] draft-ietf-intarea-frag-fragile-03
>
> Chairs,
>
> I have posted a new version of draft-ietf-intarea-frag-fragile, working in comments from Tom and Brian.
>
> If you see fit, please initiate a working group last call.
>
>                                                        Ron
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org<mailto:Int-area@ietf.org>
> https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=dnt1U1J4Efpx1ypoLNGr5X-jSympqrAGJodux4abHZ8&s=35whtuRpRpLDWchEp0AJSJ0DWb1sUMYabC515g2LyjU&e=>

_______________________________________________
Int-area mailing list
Int-area@ietf.org<mailto:Int-area@ietf.org>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=dnt1U1J4Efpx1ypoLNGr5X-jSympqrAGJodux4abHZ8&s=35whtuRpRpLDWchEp0AJSJ0DWb1sUMYabC515g2LyjU&e=>