[e2e] end2end-interest Digest, Vol 19, Issue 5

[Detlef Bosau]

"S. Keshav" wrote:
> 
> 
> As your mail indicates, delay spikes are due to link-level (i.e. what is
> called 'Radio Link Protocol' or RLP) retransmissions, which attempt to hide
> link losses from higher layers. They can _also_ be caused by opportunistic
> scheduling, used, for example, in EvDO, where a mobile with a good channel
> gets all the resources, causing delays for other mobiles.


O.k. At the moment, I have no "feeling" for the effects of opportunistic
scheduling.
However, it should not really matter. In general, I think, the NO will
adapt the number of time slots
used for a packet channel to the actual load due to line switching
traffic. This will result in a increase or decrease of bandwidth
depending on the load.

Because I have no real idea about 3G networks (it´s admittedly more or
less smattering) I don´t know whether scheduling conflicts occur and how
often.
However, they would defer some radio block for some few time slots. I
think, a backoff on Ethernet might be harder ;-) I don´t think it´s
something for
a TCP sender to care about.

> 
> A possible (and perhaps only?) way in which a TCP connection gets spurious
> timeouts is as follows:
> 
> The channel is in a 'good' state wrt a particular mobile, so that a mobile
> gets all its packets through with low RTT, and it sets its RTO small. Now,
> if the channel goes into a bad state, the mobile will experience a
> 'spurious' timeout.

I think, this is thre recipe used in the hiccup-tool (I don´t remember
the author, it was an Morten Schlagers homepage for a long time and
Reiner Ludwig used it extensively in his PhD thesis. However, I don´t
remember, who originally wrote it) and in my dump "simulations" here. I
simulate a long period where
the network is in "good state", so that the variance drops near to zero,
and then I change the network to a bad state.

Having bad states to often or to close to each other will cause the
variance to increase and therefore no spurious timeout occurs....
> 
> While plausible, this scenario may not actually play out in real life (and
> in your simulations) for one or more of the following reasons:
> 
> 1. The mobile may not move, so it does not change from a good to bad area,
> staying all the time in a good or bad area.
> 

In addition: Depending on the cell size, a mobile that moves may change
the cell. In fact, this can cause a spurious timeout itself. However, I
was told a few days ago that a cell change may cause some "settling"
anyway (different timeslot allocation, different network load, different
SNR, CS, symbol set,....),
so spurious timeouts are not "the" problem in this case but more some
"collateral event", the word "damage" would be too hard.


.....
> 
> 6. Channel conditions may not differ so much in the 'good' and 'bad' states.

Or channel conditions change rather smoothly from 'good' to 'bad' from
the L3 view, because a sophisticated retransmission schemme
smoothens latency changes. I don´t know how this is done in practical
implementations. But it can be achieved quite easily with spreading
techniques.


> 
> So, there are many reasons, why, even with the known variations in channel
> delay on a cell phone link, we may not see spurious timeouts. It would be

Hence, the 
Q: uestion is: Are spurious timeouts a relevant problem? Or is this some
kind of "network´s Nessie" ?

> nice if a cell phone operator reading this list were to actually verify (or
> contradict) this using real data traces.

And I´m afraid, no one really would do so :-( Ideally, I would like to
feed a real block-level trace of a network into a simulation to see what
happens
and to study the effect of different retransmission schemes on the
latencies seen for IP packets. But I´m afraid, data like this will not
be given
to the public by NOs.

(Contraditions by operators are mostly appreciated!)
> 
> Opportunistic scheduling, will, I think, tend to exacerbate the differences
> between 'good' and 'bad' channel state (caveat #6 above). However, the other
> causes may yet cause spurious timeouts to be avoided.
> 

Q: Is this done _below_ ARQ? If so (and I expect so), a properly chosen
ARQ scheme could alleviate the effects of opportnistic scheduling.

> I should add that I am not an expert in cell phone links, so my analysis
> above is purely seat-of-the-pants, but its looks reasonable, at least to me.
> 

My expertise on this one is even much less than yours ;-) So, I´m
curious how much operators shake their heads when reading our discussion
;-)
However, they are always welcome to enlighten us with the truth :-)

Detlef

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