In message <20050127221138.0B00A1F64@fnord.ir.bbn.com>,
Greg Troxel writes:

>> >If there's a window update, the other side could have sent the ack
>> >becaues of that, rather than because another segment from us arrived.
>> 
>> Yes, that too.  But there *could* also have been a drop event, as in
>> the scenario I sketched in reply to Charles.  We can't tell which
>> (without more info, ala SACK).
>
>Sure - I thought this was the point of "don't reset dupack count, but
>don't increase it", to be conservative about being sure dupacks mean a
>packet arrived..

We're on the same wavelength, here.

>> It doesn't _nescessarily_ imply it; but it might.  I think you are
>> right about what classical classical Reno did/does, but it seems more
>> conservative to count the (same ACK, window update) segment as a
>> dupack.
>
>That causes the sender to send more, so I'd call it less conservative.
>I was trying to err on the side of our TCP sending <= what should be
>sent.

I meant "conservative" in the sense of entering congestion control one
segment earlier than if we don't increment (but also don't reset) the
dupack count in that case.

Once we have SACK, and we're talking to SACK-capable hosts, doesn't
that all become moot?



>Sure, but for any congestion control scheme one can posit a situation
>where being \epsilon more aggressive it would avoid a RTO.

I mentioned it because I thought thought that was Charles' basic point
about our NewReno bug.


[...]
>> >But it would be odd for a peer to send data and then later decide to
>> >move the urgent pointer.
>> 
>> But is it illegal?  Can a telnet client be coerced into doing so?
>
>In RFC792 I didn't find a prohibition on moving the urgent pointer,
>and a notion that sending urgent data and then more urgent data is
>normal.  So if our sender's window is closed, and the remote side
>sends new data marked urgent, there could arrive a TCP packet that is
>a dupack and updates the urgent pointer.
>
>(The BSD "OOB" mechanism [...)]

Heh, yes, thats why I asked about telnet :-/.