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

[Francesco Vacirca]

Detlef Bosau wrote:
> Hi Francesco,
> 
> Francesco Vacirca wrote:
>> Some link layers use a strongest FEC to protect header.
> 
> I heard about this and it is somewhat confusing. Particularly as I find 
> it difficult to imagine that a sender switches between different 
> convolutional codes within an IP packet. However, your post perhaps 
> gives me a clue:
>> 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)... 
> 
> Are these really different coding schemes? Or is it the same 
> convolutional code but differently punctured? So in fact, you start with 
> a hardly punctured frame, thus a Viterbi decoder would hopefully produce 
> only little bit errors, and afterwards (after the header) your frame is 
> punctured more severely?

I cannot find the reference to the UMTS specification, but in the EDGE 
system this is done by using the same convolutional code with different 
puncturing (see 3GPP TS 43.064).

> 
> Or do you, an alternate approach, use differently punctured RLP frames 
> for an IP packet´s header and tail?
>> 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.
> 
> I heard of it in the context of VoIP over mobile wireless networks.
> 
> (To tell my honest opinion on this one: That´s a hoax even not worth 
> wasting a word on it.)
> 
> 
>>
>> 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.
> 
> I think the question is: What´s the problem for this solution?
> 
> WRT VoIP the mess is clear: For a voice stream, a media stream in 
> general, you need three parts of information.
> You need to know
> - what to be played out
> - where and
> - when.
> 
> In TDM, "where" and "when" are cared for by the scheduler and so you´re 
> even free to accept errors in the "what".
> 
> In VoIP over packet switching the "where" and the "when" suffers the 
> same errors like all other data.
> 
> 
>