[e2e] TCP Loss Differentiation
David P. Reed
dpreed at reed.com
Tue Feb 10 04:31:18 PST 2009
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
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
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
> 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
> 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?
More information about the end2end-interest