In message <199804072331.QAA06624@Kowhai.Stanford.EDU>Jonathan Stone writes
>
>>I think that anything else is broken in the face of pmtu and
>>asymmetric routing.  
>
>Kevn, I am not quite arguing that. I'm just saying it's not yet a
>standard, I personally would not call it ``widely deployed'', and am
>not conviced you can rely on everybody else doing it.  

Even with the "old" scheme, I can easily come up with examples
of contrived LAN topologies that would result in a ACK for
every 8th or 10th packet.  I think that it is important that 
we do better than that.

>I'm not saying you _can't_ do in_maxmtu. I *am* saying in_maxmtu
>breaks existing required behaviour, and therefore it MUST be
>configurable and the default (MUST or SHOULD) default to off, at least
>if PMTU is off.

Yah, but this has everything to do with whether the *destination*
host has PMTU, not the source host.  We can do PMTU to our heart's
content, and if the destination doesn't, we'll still get the behaviour
you object to in your LAN example.

>>In the presence of pmtu, I'd argue that full-sized segment is
>>nearly impossible to define, and that ACKing every second segment
>>is a win.
>
>It's not that simple.  (read: wrong!)
>
>I would try a definition of ``full-sized segment'' derived from the
>instantaneious ``mtu' derived from PMTU.  And I would push that as far
>as it can go. I think it works.  I've not had time to think about it
>detail, that would take a couple of days, but apart from repeated PMTU
>oscillation within the RTT estimator's envelope, I dont see how that
>would break. (and how do you change PMTU faster than the RTT?).

Yeah, we thought about that, and for more than just a few minutes.
It seemed like it would require significantly more complex code
for a relatively small win.

>Nope. Please think harder about X11 traffic and other traffic that
>turns off Nagle.  I really, really don't want one ACK for every two
>packets on a low-bandwidth link if I'm trying to do any mouse
>movement, or keyboard input, or whatever.

Yah, but if we dynamically adjusted our idea of a "full-sized segment",
wouldn't we eventually come to believe that the X11 tinygrams
were full packets?  A very brief experiment shows lots of 32 and
64 byte segments.  Obviously we could set a lower limit and lot
lots of other stuff to complicate the calculation...

>>If Nagle is turned off and we're getting deluged with tinygrams,
>>well, then, it doesn't seem like that great a sin to be sending
>>back an ACK for every two tinygrams.
>
>There *are* scenarios where it does make a clear difference.

I'd like to hear more about these, and look at traces with
various ACKing strategies.  I don't want to deluge the LAN
with ACKs, but I similarly would like to ensure that we do enough
ACKing to avoid stretch ACKs and similar problems.

>At a higher level the problem is that you'd like to use the peer's
>dynamicaly-discovered PMTU, but it's at the wrong end.
>
>The, umm, _really obvious_ answer is to add a PMTU-change option to
>TCP and to get PMTU hosts to send an update of their effective MSS to
>the peer when the PMTU changes.  Is htere some reason not to push for
>that?  Does the tcp-impl commmunity not think it's worth the effort?

Yup.  We thought about this, too.  Think about SACK, which would
be a great big win.  Who has deployed it?   How long has the RFC
been out there?  Now think about yet another TCP option... :-)

Kevin

[Just as an aside, Jason and I are both reasonably intelligent people
who've spent much more than five minutes thinking about this stuff.
I think it is a little bogus to throw out a few obvious ideas
and ask for a patent on them, eh?]