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

[Cannara]

Detlef, this sounds very reasonable.  But remember, no matter whether there
are radio links of any sort in a path, or not, the behavior of present TCP is
disruptive of throughput as soon as even one packet isn't acked.  So, words
like differences from wired paths "nearly disappear" are begging the
question.  This is also why the belief: "The better compliance we have to the
basic system model used in TCP..." is bound to fail.  TCP is not a "system
model" in any complete sense, because its control is based on undecidable (to
it) events -- packet losses for unknown (to it) reasons.

This "system model" is extended as the false god of "TCP Friendliness".  All
adherence to it means is that reasonable TCP service will remain denied if
even 1% of packets are lost at a failing physical bus interface anywhere in a
path, radio links or not.  There's no reason to think that a transport design
which results in amplifying physical, not congestive, losses at light load is
a completed design.  It's not even an acceptable design, as various demanding
applications demonstrate.

Alex 

Detlef Bosau wrote:
> 
> 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