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

[Francesco Vacirca]

Some link layers use a strongest FEC to protect header. E.g. in some 
UMTS coding scheme the link layer employs a 1/3 codification for RLC 
header, whereas the payload can use a different scheme (e.g. from 4/5 to 
1/3)... Maybe it could be applied also to TCP. Note that this can 
decrease the goodput in case of non lossy links... obviously it depends 
on the ratio between useful bits and transmitted bits.

In the 802.11 standard some part of the packet (MAC header) is sent with 
a different rate to be more protected against channel impairments and 
also for compatibility purposes. A cross layer approach could adopt low 
rate also for TCP header (also IP obviously)... but I do not think that 
the benefits are more than disadvantages.

One more thing... in case of Michael experiments, are the packet losses 
on the channel due to SNR fluctuations or due to MAC collisions?
In the second case, it is quite normal that the whole packet 
(header+payload) is corrupted.

Francesco



Michael Welzl wrote:
>>> 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?
> 
> I think that these methods of ACK loss detection are interesting
> ideas, and there might be a way to intelligently combine them
> with what's already in
> http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-00d.txt
> 
> Cheers,
> Michael
>