Re: Another proposal to think about

[sytek![e-mail] (Rich Fox)]

It seems that at this point there are 2 proposed solutions to the MTU discovery
problem.

  1. RFC 1063
  2. Steve Deering's idea of using a bit in IP and a new ICMP message.

After talking with Jeff it seems that there are enough problems with 1 that
we might concentrate on solution 2.

After looking at the draft paper for #2 I have the following concerns:

  1. I really do not think that we should be changing the meaning of the IP 
     header for such a feature. My understanding is that powers above won't
     allow the IP header to change, except possibly for something absolutely
     ness. I am not sure that this feature would qualify.

  2. I feel that this is an interm solution until a proper solution is devised, 
     or this solution proves to be the best solution.

Addressing the concerns I think that using the RF bit is possibly not required
for this solution to work. In fact, I am not sure that the ICMP message is
actually required (it might be a nice thing to have in any case).
Lets look at a solution that does not use the RF bit, the following
scenarios should exist (I have only assumed TCP as the transport protocol, this
may not hold for all transport protocols):

   The TCP's send in the SYN and SYN-ACK packets MSS options that reflect the
   known MTU of their connected networks (just as they should already*). The
   smaller of the 2 MSS's will be selected as the MSS to be used in the 
   connection. This gives us an upper bound on the MTU but may still be too
   large. There may be a network in between the 2 that cannot support the
   agreed upon MTU. Thus, the following scenarios may take place.

* see scenario 2.

   Scenario 1:  Both stations have implemented the MTU discovery feature:
	1. Station A sends to station B a packet that will be fragmented.
	2. Station B receives the packet and informs the transport layer
	   what the size of fragment 0 is (Steve's paper suggests that this
	   feature is needed anyways).
	3. Station B then sends a packet back to station A with a new MSS 
	   option that resembles the size of fragment 0.
	4. If the packet with the new MSS is lost, no problem. The next time
	   Station B receives a fragmented packet it will send out another
	   MSS option. It will do this until a packet finally reaches Station A.

	Thus we see, that as long as IP supplies the transport layer with some
	information about the size of fragment 0 this solution works fine to
	a point (there are some issues that I will hit upon later).


   Scenario 2: Only one station has implemented the MTU discovery feature:
	
	This scenario will be the same as in scenario 1 except only the host
	that has implemented this feature will be able (or should I say
	have the smarts) to send the MSS in non-SYN packet. This has the 
	possible effect that if the host sending the data is the host with
	the smarts and the host receiving the data is only sending ACKS then
	the sender may not find out about the fragmentation that is going on.
	I do not feel that this will be a problem since typically if a host
	is communicating to a host that is not on the directly network it
	chooses a small MSS to be safe. I feel that this will continue such
	that the host that does not implement the discovery feature will always
	option for the smallest MTU (one that is known to be safe) and 
	fragmentation should never occur.


This solution has 1 major problem. What happens if a link comes back up during
the lifetime of a TCP connection which now increases the potential MTU of
that connection? How will the connection find out about this increase?
According to Steve's paper this really isn't a major problem at all (and I
agree). If this is an important issue then I feel that we can build a timer
in some place to try and renegotiate the MSS. I haven't specified any details
of the timer since I don't think its essential for this note.


What this solution tries to do is build upon the knowledge gained from the
previous 2 solutions while trying to minizing the required changes to either
IP or the transport protocols. I stated that this might be an interm solution
because I am inclined to think that the routing protocols should handle 
this problem. Before I comment on that any more I need to think about it. At 
this point the solution in this paper I think (after some revision) might do
the trick.

Sorry if this note is a little haphazard, but its getting late and I am trying
to get out of here since I have a long drive ahead of me for Turkey day.
Talk to you all next week.

rich