[e2e] How do we deal with mobile networks?

[Detlef Bosau]

After some recent off list discussions, I think we have some issue here.

First of all: Where is the right place for loss recovery?

Up to now, we discuss mainly two alternatives: End to End and local.

When a packet cannot be successfully transmitted via some mobile link 
due to noise, it does neither make sense to repeat it over and over 
locally nor does it make sense to repeat it over and over end to end. 
Although the latter alternative is worse than the first because /absurd 
retransmissions end to end do harm to competing flows./ The same holds 
true when we replace retransmissions by some sophisticated FEC scheme, 
as it was by Van Jacobson in "A Rant on Queues" in 2006. Despite of all 
other difficulties, avoiding local ARQ by adding redundancy, e.g. like 
in the TETRYS work by Lochin et al., uses resources which are no longer 
available for competing flows.

Now, in his talk, VJ proposes even to avoid local Reed Solomon Coding 
and the like and I completely disagree. I think we are in the well 
proven tradition of Salzers End to End paper, when we carefully consider 
were packet recovery is done best: As locally as possible.

First, there is nothing like "the universal error free FEC", any kind of 
FEC will always be chosen adequate to the link. If a FEC scheme is 
chosen to strong, the resource consumption is to expensive and the 
throughput as seen by upper layers is to small. If a FEC scheme is 
chosen to weak, a flow (and hence competing flows as well) will suffer 
from lots of retransmissions.

Second, when we want to find FEC schemes appropriate for a channel, we 
must a) have information about the noisy channel to find appropriate 
schemes and b) react timely. When we think of, e.g., HSDPA where the 
coding scheme is adapted every 2 milliseconds, it is obvious that we 
cannot timely adapt to a HSDPA link on a End to End basis.

A basic insight, which seems not to be commonly accepted to me, is that 
a link's throughput, more precisely: the time needed to successfully 
transfer a packet on the link, does not mainly depend on the technology 
in use but on the channel's properties. I was a bit confused here by RFC 
3819, where the authors write the following:
> 8.5.3.  Analysis of Link-Layer Effects on TCP Performance
>
>     Consider the following example:
>
>     A designer invents a new wireless link layer which, on average, loses
>     1% of IP packets.  The link layer supports packets of up to 1040
>     bytes, and has a one-way delay of 20 msec.

First, such a link layer inevitably needs some local FEC/ARQ mechanism. 
Second: The loss probability does not depend on the link layer but on 
the channel. Of course, a link layer may abstract this to upper layers - 
to the cost of unbounded transmission times. Particularly for HSDPA, the 
typical selection schemes for coding schemes well include "out of range 
areas", i.e. when a channel is too bad it is simply not used.

What makes me curious in the context of the aforementioned RFC is that 
the authors in the following text use well known TCP formulae, e.g. by 
Mathis or Padhye, to do throughput estimations and simply assume that 
parameters like "RTT" or "RTO" would be available in the context of 
mobile networks.
Or when it comes to the dimensioning of queueing memory, it is assumed 
that we had something like a "bottleneck bandwidth" which is the least 
throughput along the path. What is the throughput of a mobile wireless 
interface? Particularly in the context of packet switching where we 
expect packets to be delivered correctly? /Simply spoken: In the general 
case, it is unknown./

*What are my conclusions?*

 1. As soon as TCP paths include one or more mobile links, TCP RTT
    estimators, and hence derived confidence intervals like RTO, do not
    really hold.
 2. The same holds true for formulae based upon those statistics.
 3. Error recovery should be done as locally as possible. In that
    particular respect we should change our attitude from hat outlined
    in RFC 791 from
>     1.2.  Scope
>
>        The internet protocol is specifically limited in scope to provide the
>        functions necessary to deliver a package of bits (an internet
>        datagram) from a source to a destination over an interconnected system
>        of networks.  There are no mechanisms to augment end-to-end data
>        reliability, flow control, sequencing, or other services commonly
>        found in host-to-host protocols.  The internet protocol can capitalize
>        on the services of its supporting networks to provide various types
>        and qualities of service.
    to an attitude where we request a sufficiently small packet loss
    probability, e.g. 1 percent, and request an appropriate signalling
    mechanism when this cannot be achieved in order to look for a
    possibility to overcome the problem, e.g. by some route change, or
    to inform the application layer of the problem to enable appropriate
    actions. It may even be appropriate to define some technology
    specific maximum transmission time for a packet, hence we have a
    certain limit: "SDU transmission time < 0.1 seconds, SDU loss
    probility <= 0.01" - and when this cannot be achieved, upper layers
    are notified accordingly.
 4. TCP is an asynchronous protocol. We should not expect TCP flows to
    run "smoothly" with "the same rate" from End to End throughout the
    whole path. TCP packets my clump together in parts of the path, they
    may be sparsely distributed in others. Hence, we should discuss
    whether it does make sense to do congestion control, resource
    management and scheduling on a strong End to End basis, as it is
    done today, or whether we should discuss possible alternatives. 
    (This discussion is not only motivated by mobile networks, I could
    mention other reasons as well, however in this post I would like to
    restrict myself on mobile networks.)




-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130224/decfec31/attachment.html