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

[Lloyd Wood]

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.

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.

L.

Joe - the Touchidic scholar of RFCs, always ready with chapter and verse.




>Joe
>
>-- 
>----------------------------------------
>Joe Touch
>Sr. Network Engineer, USAF TSAT Space Segment
>
>
>
>*** END PGP VERIFIED MESSAGE ***