Re: [dccp] PMTU issues

[Eddie Kohler <kohler@icir.org>]

Hi Tom,

> 1)  Start the connection by sending some probe packets.  Note that this
> means getting feedback that they were delivered before going on with the
> real work.

Yes, but this could take just 1 RTT to set up -- send 4 packets back to
back with a range of sizes and wait to see what gets acked.

> 2)  Never send packets bigger than some size that's likely to be OK, but is
> probably less than the PMTU that DCCP says.  And be prepared to adjust down
> from that in the few situations where it's necessary.  It's probably pretty
> difficult to come up with this recommended "safe" PMTU.

On IPv4 networks, at least, there is a third option:

3) Send without DF and let the network fragment.  Perhaps the receiver, in
   an acknowledgement, could send an option back saying "This arrived
   fragmented".  Problem: IPv6 compatibility.

The new PMTU draft would suggest a fourth:

4) Start smaller and gradually increase your size until you experience loss.
   Use a pattern such as 

   small, small, small, small, large, small, small, small, small, ...

   Wait until the "large" has been acknowledged to increase your PMTU.  We
   could engineer it so that this probing happened independent of the
   application (for example, DCCP could send an Ack with a large payload
   area, which by definition will be ignored), so that app loss was not a
   problem.  Problem: This assumes the app can be told at any time that it
   should increase its MTU.  It may be difficult for applications to change
   their packet sizes dynamically.

Michael Welzl suggests a fifth, which would require router changes:

5) IP options for checking the PMTU.

Eddie

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html