Re: [v6ops] new draft: draft-generic-v6ops-tunmtu

["Templin, Fred L" <[e-mail]>]

Hi Fred,

> -----Original Message-----
> From: Fred Baker (fred) [mailto:[e-mail]]
> Sent: Friday, June 22, 2012 5:32 PM
> To: Templin, Fred L
> Cc: [e-mail] WG
> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu
> 
> 
> On Jun 22, 2012, at 3:35 PM, Templin, Fred L wrote:
> 
> >> The reason to not do inner fragmentation, if memory serves, has to do
> with
> >> the behavior of fragmentation in the network and its effect on
> >> communications. For example, suppose you and I are in 9K clean networks
> >> (so the TCP MSS starts out as 9K), my link to the public network has an
> >> MTU of 1500, and somewhere en route to you there is another link with
> an
> >> MTU of 1400. When I send a 9K packet, it will become six 1500 byte
> packets
> >> with a small caboose that picks up the size of five IP headers (IPv4 or
> >> IPv6), and what you will receive is six 1400 byte packets interspersed
> >> with six 100+IP byte packets, followed by the original caboose. What if
> >> the fragmenting router's queue, at the time of fragmentation, was one
> >> packet short of the needed capacity? Maybe the retransmission follows a
> >> different path and is fragmented differently, resulting in funny
> overlaps
> >> whose handling isn't very well specified. There's nothing *incorrect*
> >> about a stream of 13 packets of various sizes being reassembled, but
> >> integrating retransmissions gets messy. IIRC, they just wanted to clean
> >> that up.
> >
> > I think you could probably extend this to even worse cases
> > if you said that the 1400 link was followed by a 1380 link,
> > which was followed by a 1350 link, etc. The caboose-trimming
> > would become pathological very quickly. So, why not require
> > that fragmenting routers make all fragments to be roughly
> > the same size (instead of roughly MTU-sized) so they will
> > fit through smaller links further down the line?
> 
> 
>           OOO  M     M  GGG
>          O   O MM   MM G   G
>          O   O M M M M G
>          O   O M  M  M G  GG
>          O   O M     M G   G
>          O   O M     M G   G
>           OOO  M     M  GGG
> 
> 
> If you want to go there, there are some 20-year-old discussions I need for
> you to look at. Options proposed include at least
>   - someone (a router, a host) fragmenting traffic should make all chunks
> the same size
>   - the first N-1 chunks should be approximately MTU-sized and the last a
> caboose
>   - the last N-1 chunks should be approximately MTU-sized and the first a
> caboose

I guess you are talking about p.45 of RFC1812? I've looked
at that many times and have always wondered about the option
to lead with a caboose as the first fragment. As a receiver,
I'd like to be able to look at the first fragment as a way
of measuring the path MTU, but I don't get that option when
the first fragment is tiny. 

> There have been passionate discussions, each approach having proponents
> with believed-by-them-to-be-good arguments for their position. And I'm
> pretty sure there were other positions.
> 
> The one thing I'll take serious exception to is a proposal that a router
> reassemble packets and then re-fragment some other way in the normal
> course of doing business.

Per RFC1812, I agree for packets that are just passing
through the router, but the router has to reassemble packets
that are explicitly addressed to itself. RFC1122 also says
that the router only needs to reassemble 576 at minimum
so that is all that the tunnel near end can assume if the
tunnel far end is (or might be) a router.

> Excellent fodder for an IRTF draft. Go for it, with my blessing. I,
> personally, won't be there to keep track of the angels and pinheads...

I guess you didn't like the departure into fragmentation
technique discussions. We don't have to go there, so we
can back off from that line of discussion if you find it
offensive.

Thanks - Fred
[e-mail]