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

[David P. Reed]

The design rule of *all* Internet protocols from the beginning is that 
packets can arrive duplicated and out-of-order from the order sent.   
Inference about the state of the sender must presume that an incoming 
packet only tells you something about what was true at some point in the 
past - and lost acks could just be long-delayed acks.

ack reordering, duplication, and frank loss can be inferred only at the 
end of time (or after all potentially misrouted packets would have been 
lost due to TTL expiry).

What can be inferred on occasion is *probable* loss.   This requires a 
probabilistic model of the end-to-end IP channel, which can only be 
constructed by experiment and bayesian inference from priors.

Probable loss can be used to tweak performance, of course.   But the 
quality of such results cannot be handwaved by an analysis that ignores 
the reliability of the inference mechanism or its underlying assumptions.

Lloyd Wood wrote:
> At Wednesday 31/01/2007 16:34 -0800, Lachlan Andrew wrote:
>   
>> Greetings Lloyd,
>>
>> On 31/01/07, Lloyd Wood <L.Wood at surrey.ac.uk> wrote:
>>     
>>> It's possible for the sender to infer that an ack has been lost, based on subsequent receiver behaviour in sending a cumulative ack including packets received that the sender didn't get individual acks for.
>>>       
>> No, that was my point.  We can't distinguish between ACKs which are
>> lost and those which are never sent in the first place.
>>     
>
> Yes, we can. If a SACK block is present, it tells you which datagrams were and weren't received.
>
> If a datagram was received, an ack was sent (modulo the delack mechanism), and the datagram will not be called out in the SACK block.
>
> If the datagram wasn't received, this will be reflected in the SACK block.
>
>
>   
>> Also, having a unique identifier (like a timestamp) isn't the same as
>> having sequence numbers which can say "We're (not) consecutive".  The
>> latter can detect loss but the former can't.
>>     
>
> If you have timestamps on every ack and packet, what's the difference?
>
>
>
>   
>> Cheers,
>> Lachlan
>>
>> -- 
>> Lachlan Andrew  Dept of Computer Science, Caltech
>> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>> Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603
>>     
>
>
>