Subject: Re: pilc minutes for IETF 48

From: "Al-hussein Abou-zeid" <[email-masked]>
Date: Wed, 20 Sep 2000 17:24:02 GMT

>From: Reiner Ludwig <[email-masked]>
>To: "James P. Salsman" <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: pilc minutes for IETF 48
>Date: Tue, 19 Sep 2000 15:19:51 +0200
>
>At 20:08 18.09.00 -0700, James P. Salsman wrote:
>> >>...  There seems to be a lack of understanding about the
>> >> parameters involved, and most if not all of the important ones are
>> >> at least touched on in the DoCoMo I-D and the documents it cites.
>> >
>> > You need to be more precise. Which parameters are you talking about?
>>
>>These from 
>>http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt
>>
>>      Feature        Parameter/Recommendation  RFC/Status
>>      -------------------------------------------------------------------
>>      MTU size              1500B              N/A
>
>.....
>
>>      Window size           64KB               RFC 793  Standard
>
>.....
>>      Initial window        2 mss              RFC 2581 Proposed Standard
>
>.....
>
>.....
>>      Use of SACK           Recommend          RFC 2018 Proposed Standard
>
>....
>So really, there are not many "TCP parameters" that need to be tuned for
>wireless. In fact, I don't think there is any such parameter. The only one
>that is left from the above list is the socket buffer size, but that is not
>wireless specific but rather required by the bandwidth x delay properties
>of your path. Something the satellite people have dealt with for more than
>10 years.
>
>....
>I don't think so. There is no such thing like a "Wireless-TCP" and more
>important: there is also no need for it. TCP over wireless works just fine
>if you have the right link layer.
>

Two comments; First, the performance of TCP is sensitive to the specific 
wireless medium characteristics, especially loss behavior - see TCP studies 
on this issue in Sigcomm, Sigmetrics and Infocom 2000. So, there are no 
magic TCP values that would work for any wireless link. Second, what do you 
mean by a "right link layer". Is there such a thing? If you mean a wireless 
link that is as pure as an optical link,  or even a twisted pair, then, this 
it is probably a very special case of a wireless link.

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: Wed, 20 Sep 2000 20:23:46 +0200

At 17:24 20.09.00 +0000, Al-hussein Abou-zeid wrote:
>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.

***However***, you have to ensure that the link layer does this _only_ for 
the reliable flows such as the TCP-based flows.

There are number of studies that confirm that. Taken from a mail I had sent 
to PILC on Aug. 1st:

1. P. Bhagwat, P. Bhattacharya, A. Krishna, S. K. Tripathi, Using channel 
state dependent packet scheduling to improve TCP throughput over wireless 
LANs, ACM/Baltzer Wireless Networks Journal, Vol. 3, No. 1, January 1997.

2. D. A. Eckhardt, P. Steenkiste, Improving Wireless LAN Performance via 
Adap-tive Local Error Control, In Proceedings of IEEE ICNP 98.

3. R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, A. Joseph, Multi-Layer 
Tracing of TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings 
of ACM SIGMETRICS 99.

4. M. Meyer, TCP Performance over GPRS, In Proceedings of IEEE WCNC 99.

>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.

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.

And yes, the known problems ***can be solved at the link layer***, we need 
to be able to distinguish flow types, though.

///Reiner

---

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 21 Sep 2000 14:01:55 +0100

I agree we need to think clearly about what we are saying.

> the reliable flows such as the TCP-based flows.

Well, here I think you need to be much more specific.  What you are proposing
may well be of merit where you are able to  differentiate individual flows
AND reliably indicate which are TCP and which are UDP. It also implies
a sufficiently large link layer retransmission window, so that
window does not stall during the time to recover the worst case
loss pattern (which could be a challenge on long-delay links (e.g.
100 Mbps satellite circuit).

If you lump all flows into one link queue (perhaps because you feel some
network flows are actually GRE tunnels, IPSEC encrypted, or whatever,
then you have to be much more cautious with this recommendation, particularly
I feel when you have high link bandwidth and some UDP traffic.

Recommendations for fully reliable ARQ may also need to consider the impact
of alternate network paths which do not pass over the errored wireless link.

> 4. M. Meyer, TCP Performance over GPRS, In Proceedings of IEEE WCNC 99.

While this may be true in these studies, I'd like a clearer understanding of
the
factors, which influence this before we leap into general conclusions.

Many, although I have not examined all of these, refer to cellular
phone/wireless
links, and not to generic radio links which include satellite, high bandwidth
line of
sight, very low bit rate, etc.  I think there is evidence that at least some of
these
links have in the past performed very poorly with reliable ARQ protocols.

> See above. Such a link layer also eliminates the problem of link outages as

Link outages are a specific characteristic. May be our recommendations for
outages
should differ from other types of errors (I can see merit in this).  During an
outage
no retransmission scheme is going to succeed at the link layer - some physical
layer (coding, etc) may succeed - After an outage, we need to resume
transmission
at the link layer of the data which failed to be sent. This is what the current
draft
advises subnet designers with outages.  It is in effect a support for reliable
ARQ,
although doesn't imply you HAVE to do it this way.
.

> to TCP and/or ICMP, let's first see what we can do at the link layer to

I agree.

The problem with wireless add-ins to TCP is that they are even less likely to
be generic
to all types of links.  The information provided by any network is almost
always transmitted unreliably to the end systems, and it can not always be
be assumed that this is the only path between the end systems.

> to be able to distinguish flow types, though.

Yes, I think we need at least two scenarios here - since the advice may need to
be
different in each.

--
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 21 Sep 2000 22:52:15 +0200

>100 Mbps satellite circuit).

Sure, a link layer retransmission window should be well designed for its 
environment of operation but when it stalls, it stalls. So what? That's not 
any different from a link outage caused by some other reason.

As Vernon has pointed out in his last mail: if the link layer cannot get 
the packet across the link, TCP won't be able to do that either. So for the 
receiving application it doesn't make a difference whether packets cannot 
be delivered to it because they are held in some link layer or by TCP.

>of alternate network paths which do not pass over the errored wireless link.

We are talking of recommendations for a designer of a specific link layer. 
Why does that require considering the impact of paths that do not pass over 
that very link?

>[...]
>sight, very low bit rate, etc.

I forgot to mention the Internet Draft presented by NTT DoCoMo about TCP 
performance over W-CDMA. W-CDMA clearer qualifies as high bandwidth x 
delay. One of their key results (which unfortunately was not on their 
conclusion slide) was that they got the best TCP performance when the link 
layer error recovery persistency was high.

>I think there is evidence that at least some of
>these

So, now I'm really interested in that evidence. Where is it?

>should differ from other types of errors (I can see merit in this).

I still haven't seen any good reasons for it.

>During an
>outage
>no retransmission scheme is going to succeed at the link layer

and the transport layer. That's the point! TCP will not make any progress 
no matter whether TCP or the link layer holds on to the packets.

>- some physical
>layer (coding, etc) may succeed

Right. FEC and other physical layer mechanisms are an orthogonal issue. 
They need to be in place, anyway.

>- After an outage, we need to resume
>transmission

Resuming transmission at the link layer after an outage is what I call 
persistent link layer error recovery (ARQ). It doesn't mean that the link 
layer really tries to transmit frames all the time during the outage. It 
also doesn't mean that it buffers packets beyond a reasonable buffer size.

///Reiner

---

From: Ekram Hossain <[email-masked]>
Date: Thu, 21 Sep 2000 17:31:44 -0700 (PDT)

> layer error recovery persistency was high.

Hi Reiner:

I want to mention about some of our recent experimentations regarding
the performance of wide-area TCP connections 
in a cellular WCDMA environment. What we have observed is, persistence on
retransmission in the link layer is effective only under certain channel
load condition. In fact, in a WCDMA environment (which allows variable
rate transmission at the link layer), increasing the number of allowable
retransmissions in the link layer improves TCP goodput when the channel
load is neither too small nor too high. As the number of active TCP
connections (passing through the BS) becomes large, link layer 
retransmissions are no longer beneficial. 

Anyway, some of the results will be presented in the coming IEEE
ICPWC'2000 in India (http://www.citr.ece.uvic.ca/ICPWC2000/).    

-----------
Ekram