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

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

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Monday, June 25, 2012 9:54 AM
> To: Templin, Fred L
> Cc: Fred Baker (fred); [e-mail] WG
> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu
> 
> 
> 
> On 6/25/2012 9:20 AM, Templin, Fred L wrote:
> > Hi Fred,
> >
> >> -----Original Message-----
> >> From: Fred Baker (fred) [mailto:[e-mail]]
> ...
> >> 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.
> 
> Since there is no requirement that the first fragment be "as large as
> possible", it is inappropriate to infer anything from its size anyway.

Maybe or maybe not. If the first fragment is significantly
larger than the minimum link MTU isn't it fair to say that
it is likely to approximate the largest unfragmented packet
that can traverse the tunnel? The only risk then is in
under-estimating the tunnel MTU (and not over-estimating).

An historical anecdote - Fred B. may know more about this.
In the mid-1980's companies such as Digital Equipment
Corporation produced 1st generation Ethernet gear that
could not always keep up with wire-speed. I know of at
least one of these 1st generation NICs that would reset
itself if it dropped a packet, which happened quite
frequently if the card received a burst of fragments
from a large fragmented datagram. Was this the genesis
of the RFC1918 text that says:

  "Work with slow machines leads us to believe that if it is
   necessary to fragment messages, sending the small IP fragment
   first maximizes the chance of a host with a slow interface of
   receiving all the fragments."

??
  
> >> 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.
> 
> I don't think there's any disagreement there. There are two kinds of
> packets "router boxes" process:
> 	forwarded packets (when the box acts like a router)
> 	packets originating/terminating at the router (when the box acts
> 		like a host)
> 
> Note that tunnel ingress/egress processing falls into the latter
> category for the outer packet, and the former for the inner packet.

Right. And, the philosophy I'm suggesting is that the
router kick the can down the road as far as possible
toward the inner packet destination as long as it is
done within the specified limits for inner fragmentation
and reassembly. When that can't be done, then the router
at the other end of the tunnel has to do the reassembly.

> > 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.
> 
> RFC1122 applies only to hosts (and routers when they act as a host,

Right; router acting as host is the case of interest.

> e.g., as a source or destination of packets). And yes, 576 is the
> largest reassembled MTU for IPv4 (the largest MTU, e.g., that you can
> assume for fragments, is 64).

Did you mean 68?

Thanks - Fred
[e-mail]
 
> Joe