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

[Joe Touch <[e-mail]>]

Hi Fred,

On 6/25/2012 11:18 AM, Templin, Fred L wrote:
> Hi Joe,
...
>> 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?

No; there are no requirements on how packets are fragmented, so making 
any assumptions based on any subset of fragments is not being "liberal 
in what you accept".

> The only risk then is in
> under-estimating the tunnel MTU (and not over-estimating).

Technically that's true - any fragment you see must have gotten through, 
so you can assume that the E2E path supports at least that size fragment 
(for the given endpoints; for a tunnel that's the ingress/egress if 
we're talking about outer fragmentation).

However, I'm not sure that "at least this big" helps all that much for 
any given fragment. You'd need to see a stream over time to draw any 
reasonable conclusions.

> 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:

I think you mean RFC 1812 ;-)

That RFC includes a discussion of various rationales for how to 
fragment, and basically recommends only that routers don't unnecessarily 
create more fragments than necessary.

>    "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."
>
> ??



I would expect the excerpt above refers to systems where the need to 
create a new entry for a new fragment interferes with receive 
processing, so a small first fragment helps in that case. It does assume 
that there's no persistent reordering, and assumes a somewhat broken 
receiver anyway though, IMO.

>>>> 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.

Routers shouldn't kick problems down the road towards the destination. 
They should fragment inner packets ONLY when they need to, and that 
necessity doesn't exist for tunnels.

...
>> 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?

Yeah - typed too quick. 68.

Joe