Re: Another proposal to think about

Philippe Prindeville <philipp@gipsi.gipsi.fr> Thu, 23 November 1989 14:29 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA09431; Thu, 23 Nov 89 06:29:15 PST
Received: by decwrl.dec.com; id AA08616; Thu, 23 Nov 89 06:28:44 -0800
Received: from gipsi.gipsi.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA16642; Thu, 23 Nov 89 15:26:44 +0100 (MET)
Received: by gipsi.gipsi.fr; Thu, 23 Nov 89 15:27:08 -0100 (MET)
Date: Thu, 23 Nov 89 15:27:08 -0100
From: Philippe Prindeville <philipp@gipsi.gipsi.fr>
Message-Id: <8911231427.AA01479@gipsi.gipsi.fr>
Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
To: rfox%sytek@sun.com
Subject: Re: Another proposal to think about
Cc: MTU Discovery <mtudwg>

     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.

Just one comment here -- if the packet was a jumbogram and more than
2 derived packets resulted, I think that any fragment with the MF-bit
set (ie. all but the tail) should be usable, since they might arrive
out of order.

-Philip