OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: path MTU discovery issue
From: Greg A. Woods (woodsweird.com)
Date: Thu Sep 21 2000 - 01:26:41 CDT

[ On Thursday, September 21, 2000 at 02:54:54 (+0300), Liviu Daia wrote: ]
> Subject: Re: path MTU discovery issue
>
> It's actually more involved, see Richard Stevens' excellent book
> "TCP Illustrated" for a full explanation of what's going on. Basically,
> fragmentation can occur at several layers, and you want the sizes of the
> various fragments to be multiples to each other --- otherwise the number
> of fragments involved might even double. Among other things, this tends
> to hit slow links quite hard.

Hmmm... I can't find that little tidbit anywhere... at least not in
vol.1 and at this late hour...

IP definitely doesn't fragment in any way that'll make various fragments
be evenly sized chunks of the original -- the only thing that Stevens
says (on p.150) is that the data portion of all fragments but the last
one must be a mutiple of 8 bytes in length. In fact his example on the
next page (Fig. 11.8) shows a tail fragment with one lone data byte.

Indeed you don't really want any fragmentation in the first place, which
is the premise behind using Path-MTU-Discovery. In all but the shortest
of connections the cost of sending an initial large packet all the way
to the router with the smaller MTU link, and sending the ICMP
"needs-frag" reply, and then re-sending the data as smaller packets is
expected to be less than always requiring all the packets you send to be
fragmented by the remote router (and reassembled by the remote system).

I'm not yet convinced this is true in the real world though where most
of the small-MTU links are now on just the final hop to client systems
(eg. with SL/IP or PPP). Yes the access router has to do more work and
yes more bytes have to be tranmitted over that final hop. However the
savings of not sending smaller packets all the way from the server are
spread over all the hops prior to that last one before the client.
Indeed for short connections the retransmission of the initial packet as
multiple smaller packets may almost double the transmission time, and do
so over all hops, not to mention the additional burden on the server
itself!

I.e. I think PMTUd is just as evil, if not more so, than fragmentation,
at least in this still extremely common smaller-last-hop scenario.

Anyway, enough speculation on TCP/IP for me today..... :-) 

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoodsacm.org>      <robohack!woods>
Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com>