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

Erik Kline <ek@loon.co> Tue, 12 February 2019 18:25 UTC

Return-Path: <ek@google.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1363C12D4F0 for <int-area@ietfa.amsl.com>; Tue, 12 Feb 2019 10:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.5
X-Spam-Level:
X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFVXByrIKyok for <int-area@ietfa.amsl.com>; Tue, 12 Feb 2019 10:25:52 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D4E12785F for <int-area@ietf.org>; Tue, 12 Feb 2019 10:25:52 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id o131so6314893itc.5 for <int-area@ietf.org>; Tue, 12 Feb 2019 10:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=15nbaos2Zm1pMc8ihCQ4imzwV8s/omfjzWBg9R6hv2M=; b=XpX3NUA8uEFF7dqBlrhY9Sef+P4njTSbjh1iMfHnla+YxmxoimpvGRfw2w9PtkwGg0 vhu/fZ0wdWglMR/t5UljXdW5su6GEk3xdQHtYDp6hxVW9PF1+qjLI8/hZAtoj6hqI4pu YqXJMnb4mQYgyXyOJidILB3cRmkFT9L5RUGqY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=15nbaos2Zm1pMc8ihCQ4imzwV8s/omfjzWBg9R6hv2M=; b=bZNrS8pCpeFuD02e/jZPPQ0hnBv2gUDJAwbzke0IA16mNLwnKTv8adBUO/IGDgLuA0 c9STTHaqYv3vE+VCJxjz34d1gVUTId+ETJX5Ry79oEWqB7yuFS2WygSTQyn4EiLNWRwU 2Zgf3AnIi22K3BMhEYcdd6BU1iyob+XQglmpsiylvVWvwX8WH1n0kVpKjSRReDrtznpT g3O4SK0Gn+zvpZuPMZjxVqcabbM4NeJIGw9Q6COTFfqttoCX+yuCHXt0WAennTWUrns0 UiPiJun5C7rlkZHf8YM8bAO0Xygx6/xYYw+uvpcsk27Jx+F+fAFgWbYOQGDUm4IoEs2Y Cr0g==
X-Gm-Message-State: AHQUAuYcfplwTD2nQm+x341iYLdZ0QCUQ4TbL49Wdc60xRTWX8hvZGkH 3qLwpzQs70pyiXbCRzJmj5VOIJQJI3Klm6nBzi5tYg==
X-Google-Smtp-Source: AHgI3IZsCAILUhaZKAA0PALjqZjcSW/j+j0Muhs8BZXAIhlcdqzehFUj37TvjckK3EKAuwb5N93QfY2tGjqQboO/Mh8=
X-Received: by 2002:a6b:b790:: with SMTP id h138mr2626018iof.114.1549995951005; Tue, 12 Feb 2019 10:25:51 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR05MB42453AB041957B3241F96207AEC20@BYAPR05MB4245.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB42453AB041957B3241F96207AEC20@BYAPR05MB4245.namprd05.prod.outlook.com>
Reply-To: ek@loon.co
From: Erik Kline <ek@loon.co>
Date: Tue, 12 Feb 2019 10:25:39 -0800
Message-ID: <CAAedzxr1Gz2yqHjMM56S4pv3T6PLygnHCuStSqyX6VWURAmX9w@mail.gmail.com>
To: Ron Bonica <rbonica@juniper.net>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/uFqgMLPtvMGFnakrx0uD2jI2sfo>
Subject: Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2019 18:25:54 -0000

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 <rbonica@juniper.net> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area