[e2e] Opportunistic Scheduling.

[Detlef Bosau]

Caitlin Bestler wrote:
> end2end-interest-bounces at postel.org wrote:
>   
>> I wonder, why there is absolutely no comment on my post. I
>> expected at least some criticism or contradiction. Or does anybody
>> agree? 
>>
>> Detlef
>>     
>
> My hunch is that this type of problem needs to be generalized
> so that variable local conditions can be fed back to end-to-end
> congestion/flow control in a way that is both effective and does
> not require the end-to-end logic to understand exactly what the
> local issue is.
>
>   

I´m not quite sure about this. Please keep in mind that wireless network 
conditions may change several times within the transport process of one 
single IP packet. From that perspective, it is simply not possible for 
an IP sender to "follow" the wireless channel dynamics because an IP 
sender can only decide when to send an IP packet or whether to send it 
at all. This is perhaps far to coarse for wireless networks.

On the other hand, the question is whether TCP/IP needs to follow 
wireless channel conditions at all. Although this is frequently claimed, 
I wonder why Ethernet works. Although TCP/IP simply doesn´t care for 
Ethernet dynamics ;-)

I´m not yet convinced, that wireless channel dynamics really affect flow 
control and congestion control. As I´m not convinced on the often 
claimed dreadful spurious timeouts. Regarding spurious timeouts, I 
frequently refer to Hasenleitner et al. Either you make careful 
measurements, then you will not find spurious timeouts (or sp. t. are 
not significant), or you find a significant number of spurious timeouts, 
then..... (left to the reader).

Back to the subject: I first want to _understand_ the effects of 
opportunistic scheduling, and therefore I first want to _understand_, 
how OS works and how the actually used algorithms are justified. And 
then, let´s see, whether this results in any ramifications to the upper 
layers. If so, and if there are problems, we can look how to solve them. 
However, if there are no problems, we must not invent solutions looking 
for a problem.

And I well keep in mind, what IIRC Joe Touch wrote some months ago: TCP 
is not supposed to work perfect under any circumstances.

So, if a wireless channel is bad, the TCP connection may be bad. Period. 
You cannot make a silk purse from a sows ear.

BTW: Does someone happen to know, where I can find mappings from the 
actual SNR / C/I ratio onto the actual BLER, given a known Coding / 
Modulation / Puncturing scheme? And is there anything available about 
the policies how the MCS/PS is chosen with respect to an actual SNR?
There must be quite some literature available on this topic, however I 
frequently fail to find it :-}

Regards

Detlef




-- 
Detlef Bosau                          Mail:  detlef.bosau at web.de
Galileistrasse 30                     Web:   http://www.detlef-bosau.de
70565 Stuttgart                       Skype: detlef.bosau
Mobile: +49 172 681 9937