Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

From: Ron Bonica <[email-masked]>
Date: Wed, 25 Jul 2018 22:39:19 +0000

> 
> Message: 4
> Date: Tue, 24 Jul 2018 16:46:16 -0700
> From: Tom Herbert <[email-masked]>
> To: "Templin (US), Fred L" <[email-masked]>
> Cc: Wassim Haddad <[email-masked]>,
> 	"[email-masked]" <[email-masked]>,
> 	"[email-masked]" <[email-masked]>
> Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered
> 	Fragile
> Message-ID:
> 	<CALx6S354kjyNaMYDo-XgsuiijapONC4GH+ozH8AXw-
> tQr0Ci=[email-masked]>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Tue, Jul 24, 2018 at 3:54 PM, Templin (US), Fred L
> <[email-masked]> wrote:
> > I have an observation that I would like to see addressed in the
> > document. Some applications (e.g., 'iperf3' and others) actually
> > leverage IP fragmentation to achieve higher data rates than are possible
> using smaller (but unfragmented) whole packets.
> >
> > Try it - by default, iperf3 sets an 8KB UDP packet size and allows
> > packets to fragment across paths that support only smaller MTUs. I
> > have seen iperf3 exercise IP reassembly at line rates on high-speed links,
> i.e., it shows that reassembly at high rates is feasible.
> >
> > We know from RFC4963 that there are dangers for reassembly at high
> > rates, but there are applications such as iperf3 that ignore the
> > "SHOULD NOT" and leverage IP fragmentation anyway. So, should the
> "SHOULD NOT" have an asterisk?
> >
Fred, Tom,

The draft doesn't intend to forbid fragmentation in all cases. It is perfectly appropriate some scenarios.

I will add clarifying text in the next version.

                                       Ron

> Fred,
> 
> My reading of the draft is that IP fragmentation is fragile on the open
> Internet and should be avoided for applications that run over the Internet.
> That doesn't mean that fragmentation should be avoided in all use cases. In
> particular, if fragmentation is used in a closed network with low loss and has
> appropriate security measures in place, then it can be beneficial. I suspect
> that describes the network that your're running iperf in. If this interpretation
> of the draft's intent is correct, maybe there could be some words to clarify
> that.
> 
> Tom
> 
> > Thanks - Fred
> >
************************************

---

From: Ron Bonica <[email-masked]>
Date: Wed, 25 Jul 2018 22:44:28 +0000

Brian,

I agree that we need more text in this area. Let's chat off-line.

                                    Ron

> 
> Message: 2
> Date: Wed, 25 Jul 2018 15:37:48 +1200
> From: Brian E Carpenter <[email-masked]>
> To: Wassim Haddad <[email-masked]>,
> 	"[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
> 
> +1 for adoption.
> 
> However, I am a bit concerned about this key recommendation:
> 
> >    Application developers SHOULD NOT develop applications that rely on
> >    IPv6 fragmentation
> 
> It isn't obvious to me that this is an algorithmic requirement. If the application
> runs over TCP, how does the developer ensure that TCP will use an MSS that
> avoids the need for fragmentation? (The UDP situation is a bit clearer, but
> RFC8085 introduces considerable complexity, unless we accept that the
> Internet MTU for UDP is 576 or 1280.)
> 
> Regards
>    Brian
> 
> 
> 
***********************************

---

From: Ron Bonica <[email-masked]>
Date: Thu, 26 Jul 2018 15:22:49 +0000

Joe,

Inline.......

> 
> Message: 3
> Date: Wed, 25 Jul 2018 19:14:42 -0700
> From: Joe Touch <[email-masked]>
> To: Wassim Haddad <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,
> Message-ID: <[email-masked]>
> Hi, all,
> I still think it would be useful for this doc to describe how tunnels interact
> with fragmentation (per draft-ietf-intarea-tunnels), which seems to be
> something I?ve noted several times before.

Fair enough. Let's chat offline to a) examine text that is already in the document and b) craft text that needs to be added.

                                                       Ron