[dccp] PMTU issues

["Phelan, Tom" <tphelan@sonusnet.com>]

Hi all,

Assume that even though candidate DCCP apps can tolerate lost packets, they
don't want to gratuitously cause them to be lost.  Assume also that apps
that aren't overly sensitive to delay would prefer to send a few big packets
instead of a lot of small ones.

DCCP sets an initial value for PMTU equal to the MTU of the first hop.  Data
packets are normally sent with the "don't fragment" bit set, and if the MTU
of some hop is smaller than the first, the router will discard the packet
and send a "can't fragment" message back to the source.  When the source
DCCP receives the "can't fragment" message it adjusts the PMTU down.  But
that packet has been lost, and unlike TCP, it won't be retransmited.

So, if an app uses that initial PMTU value, and it's too big (which seems
fairly likely in this world of tunnels of various kinds),  it's going to
routinely lose its first few packets (maybe only one).  I can't imagine that
this is a situation apps would like.

So, assuming that this is a real problem, there are two solutions I see,
neither of them very elegant:

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.

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.

Comments?

Tom P.

_______________________________________________
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