[e2e] How do we deal with mobile networks?
fahad.dogar at gmail.com
Sun Feb 24 07:51:45 PST 2013
Your may find our work on segment based transport relevant to this
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
> 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
> 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...
More information about the end2end-interest