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

[Tom Herbert <[e-mail]>]

On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont <[e-mail]> wrote:
>
> On 4/9/19 18:26, Templin (US), Fred L wrote:
> > Hi Ole,
> >
> >> -----Original Message-----
> >> From: Ole Troan [mailto:[e-mail]]
> >> Sent: Wednesday, September 04, 2019 7:37 AM
> >> To: Templin (US), Fred L <[e-mail]>
> >> Cc: Bob Hinden <[e-mail]>; Tom Herbert <[e-mail]>; Joel Halpern <[e-mail]>; draft-
> >> [e-mail]; [e-mail]
> >> 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: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>