[e2e] TCP Loss Differentiation

[David P. Reed]

I absolutely agree that there are non-congestion-related sources of 
packet loss!  All I was suggesting is that one should not use the term 
"loss rate" to characterize them.

A "loss process" would be a mathematically more sound term, because it 
does not confuse the listener into thinking that there is a simplistic, 
memoryless, one-parameter model that can be "discovered" by TCP's 
control algorithms.

That said, I was encouraging a dichotomy where the world is far more 
complicated: congestion drops vs. connectivity drops.  One *might* be 
able to make much practical headway by building a model and a theory of 
"connectivity drops".

That's all I'm trying to say.  If this clarifies my point, I apologize 
for communicating it so poorly before.

Well, actually there is one other thing I was hoping to suggest: that 
this second category called "connectivity drops" is an emergent systems 
property, and is best not thought of as a "link" property.  Link 
measurements cannot be easily used to characterize the "loss process" 
here - you need *systems-level* measurements (of, for a simple example, 
the loss events that come when a car using 3G Data is driving down the 
Autobahn with soft-handoffs between cell sites - we are not talking 
about "links" here; and the same thing shows up in 802.11s meshes, where 
I have some significant measurement experience - the OLPC XO computers 
run into this all the time because of the layer 2 mesh).

Detlef Bosau wrote:
> David P. Reed wrote:
>> I was (perhaps not very clearly) including multihop and mobility in 
>> "loss of connection" cases.   I meant loss of PHY or layer 2 
>> connectivity - not "session connectivity." Those situations do, as 
>> you suggest, drop packets when "link layer reliability" fails - but I 
>> would call the cause of that loss process a "loss of connectivity" 
>> however transient or healable.
>
> So, the question is: What is "loss of connection"?
>
> In cellular networks, this could mean a mobile is detached from its 
> base station.  It could mean as well: A mobile is not served by its 
> base station.
> Allegedly, in HSDPA a transport block (L1, L2) is not scheduled if a 
> channel's quality is too bad.
>
> So, a "bad channel" can introduce an unpredictable delay, because in 
> general we cannot predict when a channel's quality will become "good" 
> again, if at all.
> In case a block is scheduled despite the "bad channel", the block may 
> be eventually lost.
>
> In both cases, the underlying problem is the "bad channel" which we 
> can neither predict nor prevent.
>
>>
>> My main point was that these loss processes are not characterizable 
>> by a "link loss rate".  They are not like Poisson losses at all, 
>> which are statistically a single parameter (called "rate"), 
>> memoryless distribution.  They are causal, correlated, memory-full 
>> processes.
>
> Differently put, perhpas more simple: Our knowledge about a wireless 
> channel is extremely small. And from what I've seen so far even in
> scientific papers, we tend to use extremely simplified channel models. 
> E.g. _pure_ Rayleigh channels. Or we _only_ consider distance based 
> loss. (of signal strength).
>> And more  importantly, one end or the other of the relevant link 
>> experiences a directly sensed "loss of connectivity" event.
> In cellular networks, this may cause a mobile to attach to another 
> base station. This process itself may cause random loss. This loss is 
> not due
> to packet (block) corruption but due to roaming, if the technology in 
> use does not provide a handover process.
>
> Hence, there is actually more than one reason for packet loss in 
> mobile networks which is _not_ caused by congestion.
>
>>
>> Thus my point: one SHOULD NOT model practical TCP/IP congestion/flow 
>> control based on an assumption of "links" with "loss rates" as if 
>> they were Poisson loss processes.  One should instead focus on 
>> modeling loss processes that come from congestion and from loss of 
>> link connectivity or route changes arising from responses to 
>> connectivity loss in the appropriate ways that reflect practical 
>> reality.
>
> Where a "route change" (which covers my comment on roaming) may result 
> not only in packet loss but in a sudden change of path capacity as well.
>
> BTW: If HSDPA does not support handover, HSDPA is not very well suited 
> for media streaming. This is off topic in this post, but I just think 
> about it because a huge number of papers talks about media streaming 
> in HSDPA. This may work - as long as the mobile is not mobile ;-)
>
> However, what are the consequences from an end to end point of view?
>
> Do you agree that in cellular mobile networks, there is significant 
> packet loss which is not congestion related? And which may lead to 
> throughput degradation?
>
> Thanks
>
> Detlef
>