[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?
david.borman at windriver.com
Thu Feb 1 10:41:40 PST 2007
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:
>>>> 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
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
More information about the end2end-interest