Hi Detlef, <div><br></div><div>Your may find our work on segment based transport relevant to this discussion:</div><div><br></div><div> <a href="http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p13.pdf">http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p13.pdf</a></div>
<div><br></div><div>cheers,</div><div>fahad<br><div><br><div class="gmail_quote">On Sun, Feb 24, 2013 at 3:08 PM, Detlef Bosau <span dir="ltr">&lt;<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  

    
  
  <div 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 &quot;A Rant
    on Queues&quot; 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 &quot;the universal error free FEC&quot;, 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&#39;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&#39;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 &quot;out of range areas&quot;, 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 &quot;RTT&quot; or &quot;RTO&quot; 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 &quot;bottleneck bandwidth&quot; 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: &quot;SDU transmission time
        &lt; 0.1 seconds, SDU loss probility &lt;= 0.01&quot; - 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 &quot;smoothly&quot; with &quot;the same rate&quot; 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><span><font color="#888888">
    </font></span></ol><span><font color="#888888">
    <p><br>
    </p>
    <br>
    <br>
    <pre cols="72">-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   <a href="tel:%2B49%20711%205208031" value="+497115208031" target="_blank">+49 711 5208031</a>
                                           mobile: <a href="tel:%2B49%20172%206819937" value="+491726819937" target="_blank">+49 172 6819937</a>
                                           skype:     detlef.bosau
                                           ICQ:          566129673
<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a>                     <a href="http://www.detlef-bosau.de" target="_blank">http://www.detlef-bosau.de</a>

</pre>
  </font></span></div>

</blockquote></div><br></div>
</div>