Subject: Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

From: Erik Kline <[email-masked]>
Date: Tue, 12 Feb 2019 10:25:39 -0800

I think in that case it's just ensuring the MTU given to the customer
via their access link can be carried through their network without, or
which a minimum of, fragmentation.

I finally found some text to which I was referred, in 3GPP TS 29.060
(GTP) v15.2.0 section 13.2:

    All backbone links should have MTU values that exceeds the sum of
the maximum value plus the size of the tunnel headers (IP header, UDP
and GTP header) in order to avoid fragmentation in the backbone.

In this case the "fit for purpose" is clearly delineated as "carrying
GTP traffic".

I'll have to think about better text that "fit for purpose".  Can we
say that network operators who can characterize effectively the MTU
requirements of traffic traversing their network should factor in
whatever overhead their operational model requires so as to minimize,
or preferably eliminate, the need for fragmentation.

Operators that can't characterize the MTU requirements of their
customer traffic can decide if they're going to try or not, or care or
not. :-)

On Tue, 13 Nov 2018 at 12:35, Ron Bonica <[email-masked]> wrote:
>
> Hi Erik,
>
> Could you refine the recommendation a little bit? If an ISP were to ask, "What MTU is fit for my purpose?", how would we answer?
>
>                       Ron
>
>
> > Ron,
> >
> > Related to this section, at the mic I was suggesting perhaps including some
> > simple text recommending that network operators SHOULD take efforts to
> > make sure the MTU(s) on their network(s) are "fit for purpose", i.e. sized to
> > avoid fragmentation to the extent possible.
> >
> > I'm not sure yet how to better express that notion.  It seems obvious and
> > anodyne, but it can be useful to have these things captured for reference by
> > non-IETF documents.
> *****************************
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Feb 2019 11:23:42 -0800

> or preferably eliminate, the need for fragmentation.
Erik,

If they do that, I would hope that they include some headroom in their
MTU requirements to allow for extensibility. An operator doesn't want
to be stuck in a bad situation in the future when trying to deploy a
new protocol, like segment routing, that is potentially considerable
and highly variable overhead.

Tunnels have some mitigating circumstances wrt fragmentation. Often
they are used in limited domains where an operator can ensure that all
the intermediate nodes properly handle fragments and the network is
firewalled to limit attacks on reassembly. In such an environment,
fragmentation is much more viable than on the open Internet. It still
might be advantageous to limit the use fragmentation, but it's not a
requirement to eliminate it completely (that may be a much harder
prospect in practice).

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 Feb 2019 00:20:34 +0000

Hi Eric,

Most network providers abide by the policy that you describe. If all of their interior links support an MTU of N, their access links support an MTU of N minus M, where M is the highest possible encapsulation overhead.

This guarantees that MTU issues never occur on interior links. However, MTU issues can occur on provider access links. So, we still need to think about mitigations, and whether fragmentation is an attractive mitigation.

                                Ron

> -----Original Message-----
> From: Erik Kline <[email-masked]>
> Sent: Tuesday, February 12, 2019 1:26 PM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02
> 
> I think in that case it's just ensuring the MTU given to the customer via their
> access link can be carried through their network without, or which a minimum
> of, fragmentation.
> 
>     All backbone links should have MTU values that exceeds the sum of the
> maximum value plus the size of the tunnel headers (IP header, UDP and GTP
> header) in order to avoid fragmentation in the backbone.
> 
> In this case the "fit for purpose" is clearly delineated as "carrying GTP traffic".
> 
> I'll have to think about better text that "fit for purpose".  Can we say that
> network operators who can characterize effectively the MTU requirements of
> traffic traversing their network should factor in whatever overhead their
> operational model requires so as to minimize, or preferably eliminate, the
> need for fragmentation.
> 
> Operators that can't characterize the MTU requirements of their customer
> traffic can decide if they're going to try or not, or care or not. :-)
> 
> > Could you refine the recommendation a little bit? If an ISP were to ask,
> "What MTU is fit for my purpose?", how would we answer?
> >
> >                       Ron
> >
> >
> > > Ron,
> > >
> > > Related to this section, at the mic I was suggesting perhaps
> > > including some simple text recommending that network operators
> > > SHOULD take efforts to make sure the MTU(s) on their network(s) are
> > > "fit for purpose", i.e. sized to avoid fragmentation to the extent possible.
> > >
> > > I'm not sure yet how to better express that notion.  It seems
> > > obvious and anodyne, but it can be useful to have these things
> > > captured for reference by non-IETF documents.
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_int-2Darea&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > TXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=emFLkzGIF-fQ7
> > S48Z8rD2NpAlgzoAvIzozz0t7qvL2I&s=xl1riR8LmiMwXl2df4Uy117M-
> mozqtV6eXJJl
> > rue5DI&e=

---

From: Erik Kline <[email-masked]>
Date: Tue, 12 Feb 2019 16:33:54 -0800

> Most network providers abide by the policy that you describe. If all of their interior links support an MTU of N, their access links support an MTU of N minus M, where M is the highest possible enc…

Ah, well, if they already do this then perhaps there doesn't need to
be a statement recommending it then.

Fair enough.

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2019 07:27:37 -0800

First, this MTU discussion is quite vague. There are link MTUs, path MTUs, and tunnel MTUs and they’re different. 

Nobody building a network knows anything about the encapsulation overhead being used by tunnels - many of which are never even detected by operators. They might know about a few levels they think they expect, but that’s it.

There are no “guarantees” unless the operator controls the hosts that generate traffic that enters their network. This document should not refer to such guarantees or assurances.

Joe

> On Feb 12, 2019, at 4:20 PM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Eric,
>