Subject: Re: pilc minutes for IETF 48

From: "Al-hussein Abou-zeid" <[email-masked]>
Date: Thu, 21 Sep 2000 16:45:24 GMT

>From: Reiner Ludwig <[email-masked]>
>To: "Al-hussein Abou-zeid" <[email-masked]>
>CC: [email-masked]
>Subject: Re: pilc minutes for IETF 48
>Date: Wed, 20 Sep 2000 20:23:46 +0200
>
>At 17:24 20.09.00 +0000, Al-hussein Abou-zeid wrote:
>>Two comments; First, the performance of TCP is sensitive to the specific
>>wireless medium characteristics, especially loss behavior
>
>If you have a reliable link layer protocol (ARQ) _and_ you tune the error
>recovery persistency of that protocol to a high value like 64 seconds
>(TCP's max. RTO), you pretty much eliminate losses but trade them for 
>delay.
>

And, is this good/acceptable? How will this affect your TCP link? Also, 
could you please give a pointer to where exactly in your thesis (since you 
have referenced it in many previous e-mails) do you analyse this case?

>>Second, what do you mean by a "right link layer".
>
>See above. Such a link layer also eliminates the problem of link outages as
>discussed before.

I do not think that the problems an erroneous link poses on TCP can be 
treated by assuming we have a magic ARQ that turns it to a high quality 
link, without paying something for that ARQ (If we had such an ARQ, we would 
have solved all erroneous link problems whether or not we are using them for 
TCP). In theory, there _may_ exist an ARQ that would reduce the error 
probability as small as we want, but we may not want to do that - due to 
cost or due to loss of goodput (=application size / _delay_). Also, the 
correlation structure of the packet losses may come into play, so much as 
the link outage patterns, both being affected by the mobility, ...etc.

>
>So, my position is: before we start thinking of "wireless specific" changes
>to TCP and/or ICMP, let's first see what we can do at the link layer to
>solve the problem.
>
I fully agree that this approach is legitimate. But, I haven't seen the link 
changes you are proposing. ARQ infinitely overlooks a lot of tradeoffs. In 
fact, it has been known that feedback and forward error correction are not 
so different in terms of performance, so I don't see the analysis of the 
link layer changes that you seem to imply that they are solving problems.

>And yes, the known problems ***can be solved at the link layer***, we need
>to be able to distinguish flow types, though.
>
>///Reiner
>
Even assuming we can distinguish flows at the link layer, I think the link 
layer proposal "ARQ forever" deserves, at least, some evalution of its 
impact from an end-to-end prespective, as well as a per-link prespective, in 
addition to the previous comments above.

Regards,

Hussein.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 21 Sep 2000 23:33:10 +0200

At 16:45 21.09.00 +0000, Al-hussein Abou-zeid wrote:
If you have a reliable link layer protocol (ARQ) _and_ you tune the error
>>(TCP's max. RTO), you pretty much eliminate losses but trade them for delay.
>

Sections 4.1.4 and 4.3.3. Which you can also read as a paper:
http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/

>link, without paying something for that ARQ

What you pay is delay. But, for TCP this rarely becomes a problem because 
the TCP retransmission timer is way conservative (section 5.3 of my thesis 
or http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html) and 
if it becomes a problem is can easily be solved in TCP (section 5.1 & 5.2 
of my thesis or 
http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.html)

>(If we had such an ARQ, we would have solved all erroneous link problems 
>whether or not we are using them for TCP).

No, we should only use persistent link layer ARQ for reliable flows such as 
those based on TCP. Not for delay-sensitive UDP.

>impact from an end-to-end prespective, as well as a per-link prespective, 
>in addition to the previous comments above.

You're welcome to do that evaluation. Just remember that there are number 
of such evaluations by a number of authors in the literature already that 
you might want to check out first.

///Reiner