Subject: Re: Last Call for TCP Congestion Control I-D

From: "Kevin M. Lahey" <[email-masked]>
Date: Tue, 10 Nov 1998 15:13:01 -0800

In message <[email-masked]>Vern Paxson writes
>One of the likely agenda topics for Orlando is whether there are enough
>PMTU issues to consider doing a document on them.  Mark & I think the
>WG is pretty much ready to go dormant, except for that possibility.

I had three PMTU issues:  one bug, one possible problem, and 
a need for more research.

* Several stacks will mistakenly use a PMTU value as an MSS.
  The problem is that the sender correctly opens a connection to
  a receiver, and then determines a PMTU for the connection.
  If another connection is opened to that receiver, the MSS
  advertised is actually the previously determined PMTU.
  This means that the second connection can never try to increase
  that PMTU value as suggested in RFC1191.

* At least one vendor keeps PMTU values on a per-connection basis.
  This means that each new TCP connection starts over at the
  default MTU, and has to go through the PMTU discovery process.
  This seems like a lose for HTTP-style connections, but it is
  certainly allowed by RFC1191.

* Almost all PMTU discovery implementations are easily confused
  by routers that do not forward ICMP messages or otherwise 
  silently drop large packets.  Black hole detection has been
  discussed on this mailing list, but it doesn't seem to be
  getting (correctly) implemented.  I made a survey of PMTU 
  discovery algorithms about six months ago, and found that only
  Windows NT got it totally right.

  It sure would be nice to get some more experience with this and
  to hear from recent implementors (it sounds like the Linux 
  folks have done some good stuff).  It'd be nice to get closer to
  a standard for delayed acknowledgements with path MTU discovery...

Thanks,

Kevin
[email-masked]

---

From: Vern Paxson <[email-masked]>
Date: Tue, 10 Nov 1998 14:39:43 PST

> My worry here is that we could see a sender that does path MTU
> discovery and a naive receiver that does not.  Say the MSS is four
> times the PMTU.  The receiver will ACK after receiving 2 * MSS bytes,
> but this'll have been perhaps 8 segments.
> 
> The sender will get the ACK, and increase the congestion window by MSS,
> resulting in 4 new segments, plus the 8 segments acknowledged, for a
> total of 12 new segments.  Ouch!

My assumption is that MSS means the current maximum segment size, which
may reflect the value offered by the receiver during start up, or may
reflect a subsequent (smaller) value discovered by PMTU discovery.  So
the above would lead to 9 new segments, the 8 ack'd plus one more for
slow-start.

I would hope that receivers are a bit more intelligent about deciding
how much data to ack, e.g., every two segments of any decent size.  But
I don't think 2001.bis should mandate this, because we don't have a
standard algorithm to mandate.

> OTOH, if the sender only increases the congestion window by the PMTU
> value (rather than MSS), then its slow-start would be really slow when
> coupled with the reduced number of ACKs...

Yes, though I suspect that, in general, receivers that offer large initial
MSS's care enough about performance to also ack fairly often in order to
open the window quickly.

> Ouch, that's where I'm obviously slipping up.  I'd sure like to see
> these standards updated a bit to take PMTU and other advances into
> account, but I guess we're pretty much just trying to get folks to get
> the original stuff right...

Right, that's what 2001.bis is trying to do.  We can also consider writing
Experimental RFCs on tweaks to 2001.bis (such as the New Reno I-D).

		Vern

---

From: Rick Jones <[email-masked]>
Date: Tue, 10 Nov 1998 16:31:10 -0800

My favorite issue with PMTU is that the base RFC states that after the
PTMU timer expires, the PMTU route should have the MTU reset to the
local link MTU. 

If you do this on the great big Internet, you end-up slowly (or quickly)
accumulating PMTU routes.

So, if we want to add clarifications to PMTU, stating that it would be a
good idea to have some means to cull old PMTU routes from the routing
tables would be a good idea.

rick jones

-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, or post, but please do not do both...
my email address is raj in the cup.hp.com domain...

---

From: "Steve Alexander" <[email-masked]>
Date: Tue, 10 Nov 1998 18:20:45 -0800

> tables would be a good idea.
 
I found that deleting the PMTU route was semantically indistinguishable
from leaving it around with the link's MTU.  I guess I must be a
scofflaw, but I still believe in the "running code" idea.

-- Steve