<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
After some recent off list discussions, I think we have some issue
here.<br>
<br>
First of all: Where is the right place for loss recovery?<br>
<br>
Up to now, we discuss mainly two alternatives: End to End and local.<br>
<br>
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 <i>absurd retransmissions end to end do harm to competing
flows.</i> 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. <br>
<br>
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.
<br>
<br>
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. <br>
<br>
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. <br>
<br>
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:<br>
<blockquote type="cite">
<pre>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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
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? <i>Simply
spoken: In the general case, it is unknown.</i><br>
<br>
<b>What are my conclusions?</b><br>
<br>
<ol>
<li>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.</li>
<li>The same holds true for formulae based upon those statistics.</li>
<li>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
<blockquote type="cite">
<pre>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.</pre>
</blockquote>
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.</li>
<li>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.)</li>
</ol>
<p><br>
</p>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>