Re: Another proposal

[sytek![e-mail] (Keith Mc Cloghrie)]

> 	 Here's the proposal: As in RFC 1063, the sender attaches an MTU Request
> 	 option to some of its outgoing datagrams.  The option is updated by
> 	 routers along the way.  When the last-hop router is reached (i.e.,
> 	 a router which can deliver the packet directly to the destination
> 	 host), that router now knows the path MTU.
> 
> Without commenting (for now) on the substance of this proposal, I
> should note one or two glitches with it.  First, the last-hop router
> does not necessarily know the host's MTU.  From the Host Requirements
> RFC, it is not clear that hosts are required to accept packets of
> length greater than 576, regardless of the MTU.  

Are you referring to paragraph 3.3.3-Discussion-a) of HR RFC.
If so, I think that paragraph is considering the case of MTU < 576, 
where the fragments need to be put back together; as such, it is not
requiring the receiver to be able to re-assemble a datagram 
larger than 576.

In general, there's a danger of confusing MTU and MSS here.
If the transport-layer/application cannot accept a datagram 
of at least the local MTU size, then it must use MSS (or some 
equivalent) to limit the size of the incoming messages, i.e.
set MSS < MTU.  The purpose of MTU-Discovery is for the case 
where MSS > MTU.

This leads me to a further thought: I suggest that responding
to MTU-Discovery should be mandatory, but being able to invoke 
MTU-Discovery should be optional, i.e. all Hosts MUST respond 
to MTU-Discovery mechanisms, but hosts MAY implement the invocation
of MTU-Discovery mechanisms.

Keith.