MTU path discovery and IPSec
Joe Maimon
jmaimon at ttec.com
Fri Dec 5 01:27:17 UTC 2003
Valdis.Kletnieks at vt.edu wrote:
>On Thu, 04 Dec 2003 18:03:38 EST, Barney Wolff said:
>
>
>
>>That's not how PMTUD works. If DF is set, you discard the packet and
>>report back with ICMP. If DF is not set, you frag the packet - but
>>that's not PMTUD, because no report ever goes back to the sender.
>>
>>
>
>Oh, so we compute ONE number if DF is set, saying what number we think they
>should use - but if DF *isn't* set, we use a different number. Sounds like more
>complicated code that's just there so it can sink its teeth into the rump of the
>first banana-eating NOC dweller that has to figure out what's wrong....
>
>Unless of course there's a *reason* we want it different? Though it escapes me what
>it might be....
>
>
As I have said previously, some reasons are that
A) Your fragmenting the packet anyways, thus there will be extra header
overhead. Splitting that overhead into 1 big and 1 small packet does not
seem to be a performance win**.
B) Fragmenting into equal sizes may mean that equipment can treat them
more equaly and may reduce Out of Order fragments, which is easier on
state keeping devices.
C) Equal buffer treatment may mean easier handling of switching and
reassembly, I havent thought this through.
D) And the best part, avoid the insult to injury by lessening the chance
that further fragmentation will occur on the packet. Picture a packet
coming in from ATM to Ethernet to PPPoE through Ipsec. How many
fragments is that? How much overhead?
As far as code goes how is that a problem? One assumes the length of the
packet is there already. SO all we have to do is divide in half use that
number and use it instead of the value of next_hop_mtu.
And we use different numbers because when DF is set our only option is
telling the sender to lower. Lower to what? Well to what we know is
good. How do we know the next hop isnt even lower? Well we should know
if its in the same AS, otherwise we just do our best. And besides, PMTUD
is a performance orientated feature. One would like to avoid
compromising the performance gains. The precise maximum path MTU is
exactly what the sender wants to find out. So give it.
But IP without DF is best attempt delivery. So do whatever will be best
compromise. And we are fragmenting anyway... (GOTO START)
**But, one case where this could be undesired is by causing buffer
fragmentation.
More information about the NANOG
mailing list