Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

Tom Herbert <tom@herbertland.com> Thu, 05 September 2019 14:31 UTC

Return-Path: <tom@herbertland.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 04BE81200E0 for <int-area@ietfa.amsl.com>; Thu, 5 Sep 2019 07:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 E6VjdsgJa6g0 for <int-area@ietfa.amsl.com>; Thu, 5 Sep 2019 07:31:32 -0700 (PDT)
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (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 63FC41200DB for <int-area@ietf.org>; Thu, 5 Sep 2019 07:31:32 -0700 (PDT)
Received: by mail-ed1-x543.google.com with SMTP id y91so2872660ede.9 for <int-area@ietf.org>; Thu, 05 Sep 2019 07:31:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=G4RT4WJCo0lhFRIPaQ6rMKOZVwPiWga6Ustpk2l4xrg=; b=iJiMei6SGDo4Tc6ZadZc4BUGyBJmRjsIkFkFpWVv4ITkT4MvHhImV5WWp4t9Zeo/Kx mV/83k3UF8p0NgMbTBaipg5zMBHw+g9EijewmIGh8C0n8MkgREI/aV9tln551QwBeBp6 QqOZ4og6SRUH5RYfF6wPdSfnlO49QHZsKJAcgH9yR005LSBnCG1/gBU57lmHI+PudtRe TliDhwKeMxbBlKawVpuCv2Xet3mtJIYaEyDo0/FVRsOOkarU5D8qaiivOS8zlXiTnxM8 r2+p9V4xcNWfRhJNMWFxEAoqST1ethBDmRRI2fd5LyWTN2Ih+WcR8sv0JRj+ZHEyy04D F4xA==
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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=G4RT4WJCo0lhFRIPaQ6rMKOZVwPiWga6Ustpk2l4xrg=; b=BeX6G37bYO5qE2UQsDa/913XWfU5wOzguFswo5FuZ9miKyy9OrqvbfUsqSb15cdRpD t1HVoitbWGQArSEeq8hYwurVxyTx9oPRMo09OAjrVrQnnrkj1YoFxh/YtlA6ABGpxzpW qfMlm2/k2NmwcXbVUSURiKomGqRLEANLRYqVIc1RuptFCm8yNOU8s2h72aH38zW2yolM 9ot9e5rAOjg++32Qxs/f4crDMkgDMR+N8qiD3IGqqyzCN2QnXR8s8KxYK8qTJ2vw1JPG K361mTz6RDp10ZkX/DWVD8+pwSedTUCimO/ePa1R8oxnyDX3bxbodYSg16Nezbkuzk80 2e8Q==
X-Gm-Message-State: APjAAAWva2lsFzQd7JozBOFPfcAHInt3hDoPrEtcOWT8Ic14rIv/ZNL7 h8YH5i7vq6zkr+j7SKPKtaJuoGxI+bY0KXRLhAGH5A==
X-Google-Smtp-Source: APXvYqyk4Drjgh58RvOEEfhBLzDouN5uGf5wF2AaukDx38dZizvFAzX9RzhOjcTRNElODqeMh3l5ymyN8mYhmlsm2s8=
X-Received: by 2002:a05:6402:286:: with SMTP id l6mr4124783edv.111.1567693890906; Thu, 05 Sep 2019 07:31:30 -0700 (PDT)
MIME-Version: 1.0
References: <156751558566.9632.10416223948753711891.idtracker@ietfa.amsl.com> <B7C5DF29-92B2-477B-9C30-F47E338038EE@strayalpha.com> <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <9331E721-F7F8-4C22-9BE4-E266726B3702@gmail.com> <7bfbaf5fa12c4a9bac3e46ece5dfdcde@boeing.com> <0BF34BFA-5F30-4EE1-9F5E-18D9ECA8D424@gmail.com> <CALx6S37xhhS5ezhJu6-HQmftwY9cBzuCxeaW9thTbKBa2hizcw@mail.gmail.com> <A8A10E03-6EEC-4F60-A213-7D66084BA754@gmail.com> <09d0dc428430407f8154f40d47a417dc@boeing.com> <67823455-8FCB-4C9E-8B78-41F2E99BDC21@employees.org> <1f5edd49236649929599820764dedb4e@boeing.com> <D80F747F-6F23-45C9-AE8B-5C059C5AC8DE@employees.org> <47aafc6dbef24b2ba76b81f95dbbedcb@boeing.com> <4461d66b-797c-4a14-b721-b6089221f1e1@si6networks.com>
In-Reply-To: <4461d66b-797c-4a14-b721-b6089221f1e1@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 5 Sep 2019 07:31:19 -0700
Message-ID: <CALx6S34hZX+OdT5yyw3Jh-iHZ3mRNsFuHXsaZnpZHevGaGifrg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Ole Troan <otroan@employees.org>, Bob Hinden <bob.hinden@gmail.com>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ONUTWF09M3xlgYbJLfpXE_8w9D4>
Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
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: Thu, 05 Sep 2019 14:31:35 -0000

On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> On 4/9/19 18:26, Templin (US), Fred L wrote:
> > Hi Ole,
> >
> >> -----Original Message-----
> >> From: Ole Troan [mailto:otroan@employees.org]
> >> Sent: Wednesday, September 04, 2019 7:37 AM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Tom Herbert <tom@herbertland.com>om>; Joel Halpern <joel.halpern@ericsson.com>om>; draft-
> >> ietf-intarea-frag-fragile@ietf.org; int-area@ietf.org
> >> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
> >>
> >> Fred,
> >>
> >> I removed the IESG from this list, as we seem to have drifted into a more general fragmentation discussion as opposed to discussing
> >> the exact changes to this draft.
> >>
> >>>>>> Why is that more useful than what is in 3.5? If it’s not making a recommendation, why call this out in the introduction.  There are
> >> lot
> >>>> of
> >>>>>> other things it doesn’t make recommendations about that aren’t in the Introduction either.
> >>>>>
> >>>>> Because it sets a more appropriate tone and lets the reader know from the onset that
> >>>>> fragmentation and encapsulation go hand in hand. And tunnel fragmentation avoids the
> >>>>> issues raised by others in this thread.
> >>>>
> >>>> While inner fragmentation ensures the fragment will reach the tunnel tail end, a tunnel endpoint will typically not reassemble that
> >>>> fragment, so will generate fragments after the tunnel hop.
> >>>> Inner fragmentation is only available on IPv4.
> >>>
> >>> Not true. For IPv6 packets, simply insert a GUE header or an RFC2473 header and
> >>> fragment on that. The fragments will be reassembled by the tunnel tail end, then
> >>> passed to the next hop as a whole IPv6 packet. The fragmentation footprint is
> >>> therefore the same as the tunnel footprint.
> >>
> >> Is that not the exact definition of outer fragmentation?
> >
> > No. I am talking about outer header (OH) followed by tunnel header (TH) followed
> > by inner packet (IP). Recipe:
> >
> >   1) wrap the IP in a TH to create a tunnel packet (TP)
> >   2) fragment the TP
> >   3) encapsulate each tunnel fragment in an independent OH
> >   4) send each outer packet (OP). These will look like ordinary
> >        unfragmented IP packets, but will contain a tunnel fragment
>
> This looks like a recent claim from the IAB that QUIC has shown that it
> is possible to deploy new transport protocols on the Internet. -- when
> quick employs UDP, and hence from the pov of the Internet, UDP is the
> transport protocol.
>
> Same with your example: you are tunneling your fragments. The Internet
> will not see fragments. *That* is why it would work.
>
> i.e., if you want fragmentation to not be fragile on the Internet, the
> trick is that packets shouldn't look like fragmens ;-)
>
Fernando,

Sure, if we dress up protocols in UDP there is a greater probability
they can traverse the Internet. But this doesn't always work and it's
fallacious to think that unbiquitously solves the problem of protocol
ossification. I really wish the IAB would look at the issues of wide
spread middlebox non-conformance-- this is the root problem and a
fundamental deterrent to evolving the Internet IMO.

Tom

> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>