[e2e] How do we deal with mobile networks?

[Fahad Dogar]

Hi Detlef,

Your may find our work on segment based transport relevant to this
discussion:

 http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p13.pdf

cheers,
fahad

On Sun, Feb 24, 2013 at 3:08 PM, Detlef Bosau <detlef.bosau at web.de> wrote:

>  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:          566129673detlef.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/43cb1087/attachment-0001.html