[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?
francesco at net.infocom.uniroma1.it
Thu Feb 1 02:24:50 PST 2007
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.
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
More information about the end2end-interest