[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?

[David Borman]

On Feb 1, 2007, at 9:54 AM, Lloyd Wood wrote:

> At Thursday 01/02/2007 06:05 -0800, Joe Touch wrote:
>
>> Lloyd Wood wrote:
>>> At Wednesday 31/01/2007 16:02 -0500, Sushant Rewaskar wrote:
>>>> Hi,
>>>> I agree with Lachlan. In TCP there is no way to know when an ack  
>>>> is lost as
>>>> it carries no "sequence number" of its own.
>>>
>>> It can - timestamps are used for disambiguation, and they
>>> disambiguate the acks. They can act as unique sequence numbers.
>>
>> How so? RFC 1323, Sec 4.2.2:
>>
>> "Based upon these considerations, we choose a timestamp clock
>>         frequency in the range 1 ms to 1 sec per tick.  "
>>
>> That suggests that timestamps need not be unique by themselves.
>
> Any implementer would be stupid to actually follow RFC1323 and send  
> actual timestamp values in the packet - that's a massive DoS hole  
> just waiting to be exploited.

That's a bit harsh. :-)

>
> Instead (as I mentioned previously in this thread), the sender  
> would have a table of timestamps and associated unique keys for  
> each packet sent out. You'd send the key in a packet, and on  
> receiving the same key reflected back you'd do a match and lookup.  
> This closes the DoS hole - matching a specific key value exactly is  
> much harder than just faking a timestamp value to lead to spurious  
> RTT estimates, and not giving away internal timestamp values also  
> prevents the kind of how-long-as-this-box-been-up profiling done by  
> e.g. Netcraft.
>
> The timestamps don't have to be unique. The keys to the timestamp  
> values do.
>
> This code is probably more straightforward to implement than, oh,  
> SACK scoreboarding.

If you are concerned about bogus Timestamps coming back, you don't  
have to hide them.  Just as you suggest using unique keys, you would  
just keep track of the actual timestamp values that you have sent.   
It shouldn't be any more work to keep track of and match exact  
timestamp values than keeping track of and matching your unique key  
values.

Besides, using keys instead of Timestamps will break PAWS and render  
your connection unusable if the value put into the Timestamps option  
ever goes backward.  The unique key generation would need to follow  
the requirements in 1323 for filling in the Timestamps option; i.e.  
the sequence of unique keys would need to look something like a  
sequence of timestamps.

Also, there is no requirement that the Timestamps values reflect  
actual clock values, or that they be consistent across connections.   
Each connection can start at a random value for the starting point  
for ticks on that connection.  They can even represent different  
scales.  PAWS doesn't need to know what the timestamp values  
represent, it only depends on the fact that the values are increasing  
over time.

			-David Borman