Maybe I'm not sure exactly what is up here....

Surely the path MTU discovery has to be done separately by both ends.
(it is quite easy to arrange completely different routes for the two
directions of a single connection - phone line and satellite?)

This puts the onus on the transmitting end to ensure it doesn't break
the valid MTU.  The 'other' end will (must?) either determine an
accurate mac MTU or use a horribly small one, the value 'our' end
used won't (shouldn't) affect its calculations.

    David

(PS I've no idea what the NAT code is (should be) up to...)

----- Original Message ----- 
From: <kml@selresearch.net>
To: David Laight <david.laight@btinternet.com>
Cc: <tech-net@netbsd.org>; <current-users@netbsd.org>
Sent: Tuesday, December 04, 2001 9:29 PM
Subject: Re: Patch for timiting TCP MSS (i.e. for new PPPoE) 


> In message <003f01c17cda$353eafe0$0100a8c0@snowdrop>"David Laight" writes
> >Is it possible - of course it is :-) everything is possible... - to
> >dynamically determine the TCP MSS for a given connection?
> 
> It is certainly possible to detect and work around path MTU
> discovery black holes.  Itojun has a patch to do it for NetBSD.
> You're describing here pretty much what it does.
> 
> The problem is that we're concerned about the *other* end of
> the connection, which needs to implement it as well.  It seems
> quite a bit tougher to detect this dynamically, and restart
> the TCP connection on our end with a smaller TCP MSS.
> Proactively making the MSS smaller (without some knowledge
> of a problem) sorta ruins the whole point of path MTU discovery.
> 
> If you can come up with a way to do it, though, it might
> be a win.  Good luck!
> 
> Kevin
> kml@selresearch.net