[e2e] Reacting to corruption based loss, and some remarks on PTE

[Detlef Bosau]

sampad mishra wrote:

> As we know packet loss (due to corruption) is significant in wireless
> and is mainly due to fading when their is shift from 1 AP to another .
> I  think it would be better if the sender decreases the rate rather
> than sending data at the same rate considering the fact that data will
> be lost...

That´s the rationale behind e.g. M-TCP (Brown, Singh, 1997).
IIRC, Brown and Singh slow down a TCP sender in the Internet which sends
data to a mobile receiver by shrinking the receiver´s advertised window
(AWND) in handover periods.

> I mean their is no point losing more amount of data by continuing to
> send data at the same rate when we know that packets are getting
> corrupted.


To my understanding, there are two issues.

First, a sender has to recover properly from corruption when packets get
lost. In mobile networks (UMTS, GPRS) loss rates in a channel without
any kind of local recovery may become that high that there would be
hardly any throughput at all if error recovery would be done on a packet
level. Unfortunately, mobile networks suffer from high packet corruption
rates not only in case of roaming but for a number of other reasons as
well (shading, multipath fading,...). Please note: I put the emphasis on
_packet_ level here. Therefore, local recovery in mobile networks is not
done on a packet level but typically mobile networks split
up IP packets in smaller portions, so called "radio blocks", which may
have a size of e.g. 171 bits. Please note: This is only one value, I´ve
found somwhere in literature. AFAIK, Manfred Taferner (Vienna) has
worked the pros and cons for different radio block sizes in his PhD
thesis. Typically, mobile networks use a Radio Link Protocol (RLP) which
bascially consists of a combination of Automatic Retransmission reQuest
(ARQ) protocol and Forward Error Correction (FEC). Because bit
corruption typically occurs in a bursty manner in mobile networks, RLP
typically employs block/packet interleaving mechansims in order to keep
the FEC overhead reasonably small. 

Second, and that´s the focus of the loss differentiation work, a sender
who experiences packet loss decreases its congestion window (CWND). It
is the particular focus of Brown and Singh, that a TCP sender shall
_maintain_ its CWND even in presence of transient disconnection / reate
decrease in case of roaming.

Now, my very concern is that these two issues are often mixed up.
Particularly, we have to carefully distinghuish between 802.11 networks
(e.g. WLAN)
and mobile networks here. Particularly in WLAN, the problem sometimes
appears to me a little bit overly exaggerated. When those networks are
properly set up and are being run as designed, nowadays WLAN plants
achieve BER less than 10^-6 which is comparable to early Ethernet
plants.

So, in my opinion (and I´m very interested in any comments on this one),
in WLAN we can simply leave the whole matter alone, shut our eyes
and forget about the missing wire. 

I know that WLAN channels may become noisy and distorted e.g. in the
presence of ferroconcrete walls etc. But I said: "properly set up and ..
being run as designed." And since we all konw that ferroconcrete
interferes with wireless communication, we can place access points and
antennas on each side of the wall and interconnect them using e.g.
Ethernet. Likewise, we should obey velocity contraints etc. 

There are numerous problems which may occur in WLANs, but we must
carefully distinguish whether these are structural problems of TCP or
simply consequences of inappropriate / wrong network operation. (Or, as
an allusion to a pretty well known phrase by AST: Never overestimate the
range of a motor car
running out of petrol.)

In my humble opinion (and as usual, I´m willing to take punishment) in
networks suffering from heavy loss, the problem is not TCP congestion
control but TCP retransmission. Of course, both problems coexist.
However: If you consider a 3G mobile network _without_ any RLP, you
would be not so unlikely to experience packet loss rates of 50 % or even
much higher. And in that situation, the congestion control problem is
the mouse. And the time and bandwitdh spent for retransmission are the
elephant.

Even more precisely: The retransmission problem is not really due to TCP
but due to the size of IP packets. This is the very reason why these
are broken down into pieces on mobile links.


> So I think its not much of a worry if sender reacts to a corruption
> like congestion for some cases atleast for the time being, till we
> find the reason for corruption and react accordingly.... Main point is

Now, the problem is that in case of frequent corruption based loss, the
sender might nearly stop sending.

Howoever, I think we must be careful to put the focus on the correct
problem.

Simply spoken:

1: "WaveLAN is fixed LAN". (even more AST: The metric ton of salt.)
2: In mobile links, corruption loss can be neglected due to the use of
RLP.

So, in mobile networks, problems for TCP are reduced to (following
Reiner Ludwigs PhD dissertation) 
-spurious timeouts,
-transient disconnections,
-scheduling problems,

With respect to this threads subject this means: In mobile networks,
corruption based loss are made (nearly) disappear, and so does the
problem.

However, the other side of the mountain is how a mobile link employing
an RLP appears to an Internet sender. One example, as you point out, may
be a decrease of bandwidth (or more precisely: achievable throughput) in
case of handover. 

This may require a sender slow down.

In M-TCP this is achieved by shrinking AWND, which may result in a
number of difficulties. E.g. shrinking / clamping AWND conflicts with
the original AWND semantics: To my understanding, the purpose of AWND is
mainly to slow down the sender if the receiver´s _application_ is not
able / willing
to accept any data from the receiver´s socket. (E.g. if the stone aged
netscape release on my even older desktop PC collapses when it is
flooded
by my DSL line ;-) ) Another problem is that it´s not an easy task to
find out the appropriate AWND which is necessary to have the sender
send at the correct rate. It may be even difficult to decide, whether
clamping is even necessary. Imagine a situation when a flow is already
restricted to a rate the mobile link can carry by some bottleneck in the
wired part of the connection.

For these reasons I propose the PTE mechanism described in
http://www.detlef-bosau.de/043.pdf . The key idea is to make a mobile
link appear like
an ordinary wirebound link, the storage capacity and bandwidth of which
reflect the properties of the mobile link. The key idea immediately
follows the congavoid paper by JK and MK, that a network is essentially
described by its storage capacity and its bottleneck rate and a TCP
sender is correctly paced by the receiver´s ACK packets when the flow is
in "equilibrium state", i.e. CWND is correctly set to the (flows fair
share) of storage capacity. The PTE mechanism is intended as a necessary
extension for PEP/split connection approaches and aims to maintain the
original semantics
of CWND, AWND and ACK pacing in TCP.

One could simplify my approach that way, that it aims to make the mobile
network disappear to the sender. The sender shall not see any difference
between
a pure wirebound part and a part with a mobile last mile. And the
rationale for PTE was whether this is totally achieved by existing PEP
(in my opinion
not quite) or wheter there remains something to be done on that matter. 

Although the PTE work seems to be off topic with respect to the threads
subject, it was _exactly_ the question raised in this thread which
motivated my work.
This work is intended as an _extension_ to existing approaches and aims
to bring more compatibility and interoperability in heterogeneous (e.g.
wirebound/mobile) networks. It is not intended as a replacement for
existing approaches.

A major concern was the matter of compatibilty. There is a plethora of
approaches for successful congestion avoidance and control on the
Internet,
Active Queme Management, Performance Enhancing Proxies etc. And perhaps
there is only a very little gap. Any approach which intends to close
this gap must not break or interfere with well proven and perhaps
broadly used mechanisms. (I think, this is in the very sense of Jon
Postels "Principle of Robustness".) Therefore the general question was:
What must be done to have a mobile link appear to TCP, and the Internet,
exaclty that way as it is expected by the congavoid paper and following
ones? The better compliance we have to the basic system model used in
TCP, the less difficulties need to be dealt with when a new mechanism is
proposed or even used.

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