Subject: Re: pilc minutes for IETF 48

From: "James P. Salsman" <[email-masked]>
Date: Mon, 18 Sep 2000 02:48:08 -0700 (PDT)

Here are some questions about the plic minutes:

  http://pilc.grc.nasa.gov/pilc/list/archive/0967.html

>   TCP over Wireless draft. The working group charter specifies that 
>   PILC will produce a 'TCP over Wireless' RFC that is a meta list of 
>   the existing PILC recommendations. This was reported in Adelaide as 
>   being completed in October 1999 because Aaron had confused it with 
>   the LTN draft. Actually, it requires some work. Gabe Montenegro has 
>   volunteered to sync up with the WAP forum to see if we can build 
>   this document on a work in progress that already exists in that 
>   body. The document should be only 3 or 4 pages long and should go to 
>   wg last call by January 2001. Gabe noted that there is currently no 
>   buy in by the WAP forum as yet, he will attend a forum meeting in 
>   September and try to resolve. Several members of WAP were in the 
>   room and volunteered to assist if needed. 
 
Is this WAP "work in progress" available for public inspection and 
review?  If not, would someone who can see it please abstract it and 
post (anonymously if need be) please?  

Does any WAP product use TCP at all?

> Discussion on DoCoMo draft (draft-inamura-docomo-00.txt) 
 
  http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt

>   Aaron noted that DoCoMo would like to publish this as informational 
>   RFC, but we don't want to get in a mode of publishing RFCs each time 
>   someone does this and requested input from the group. 

I would certainly support doing anything that would encourage DoCoMo 
to use end-to-end Internet protocols, and if they are as close as that 
draft suggests, publishing it as an Information RFC might help them 
provide TCP application services more easily.

>   A speaker noted that the recommendations are pretty generic and 
>   suggested the working group use this as a starting point for the TCP 
>   over wireless document, or as an appendix to this document. Aaron 
>   suggested it might be necessary to take the simulation results out 
>   in order to use this document for the TCP over wireless 
>   document. Another speaker suggested using path MTU discovery instead 
>   of fixing it at 1500. Question: Maybe your tcp stack in the Opnet 
>   simulator is not the best TCP. Have you run this on real stacks, 
>   rather than on a simulator. Imaura - yes they have, but no 
>   published results. 
> 
>   Aaron noted that another alternative was that the DoCoMo would be 
>   sent forth as informational, and would not be a recommendation. Tim 
>   Shepard asked why would one want to disseminate this information? 
>   Doesn't seem to make sense to have multiples of TCP/some link 
>   technology. Is this advice on how to tune TCP for the handset? 
>   Response from author: yes. 
> 
>   Comment: This shows that tcp stack works over wireless error prone links. 
> 
>   Comment: Doesn't think these results are any different from what a 
>            modern TCP stack does anyway. 

I think the TCP parameters and resulting behavior might be more 
different than typical TCP stacks than whoever made that comment
might think.  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.

>   Gabe: This is similar to what was done in ecn document 

What is the ecn document?

>   Question: What bandwidth was used in the simulations? 
>   Imaura: 384kbs 
>   Comment: Doesn't think this is realistic, since this is only the 
>            rate if you are the only one in the cell. WAP is designed 
>            to use slower links. 

WAP is designed as if Moore's Law didn't exist.

> Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) 

  http://search.ietf.org/internet-drafts/draft-magret-pilc-lltcp-00.txt

>   Comment: this is probably not a good idea -- leads to ICMP flooding. 

Is there any evidence to back this comment up?  It seems that ICMP 
traffic is specifically addressed by Magret and Yang.

>   Also, if there is a long outage you do want to go through slow start 
>   again, because the network has changed. There are better link level 
>   solutions to this problem. 

Like what?

Thanks.

Cheers,
James

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 18 Sep 2000 19:24:55 +0200

>Does any WAP product use TCP at all?

Yes, the WAP2.0 does. I don't know about the availability of the specs, 
though. Have you checked www.wapforum.org?

>[...]

You need to be more precise. Which parameters are you talking about?

>What is the ecn document?

RFC2481.

>traffic is specifically addressed by Magret and Yang.

Since, it was my comment:
One piece of evidence is the problem created by the ICMP Source Quench.

In general, you want to avoid having the network signal to the end-points 
if it's not absolutely necessary. Here it's not necessary because you can 
solve this problem at the link layer (see below).

This was discussed before on this list and you can check the archive 
pilc.grc.nasa.gov/pilc/list/archive and look for the subjects: "Kicking 
TCP" and "Why we don't need ICMP SE".

> >   solutions to this problem.

Like having the link layer hold on to (at least some of) the flow's packets 
for a time on the order of TCP's maximum RTO of 64 seconds. Note, that this 
requires a link layer that is capable of seperating the TCP flows from the 
rest to not cause head-of-line blocking for delay sensitive UDP flows. 
Check out section 4.1.4 of 
http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html to see how 
this works in real measurements.

///Reiner

---

From: Vincent Magret <[email-masked]>
Date: Mon, 18 Sep 2000 13:42:11 -0500

Hi,

Regarding the discussion on the LL-TCP, the draft specifies that it is
recommended to use  link layer information when possible. This can only work
for the mobile node and the supervisor host. For the correspondent or server,
how can this node have access to link layer, since it is not connected or
linked to the wireless network?

There is indeed a need of having a message sent from the edge node (i.e. the
supervisor node) to the fixed node to inform this latter about the new status
of the link. Concerning the flooding fear, I don't think there is a risk of
getting in such situation by the time the tuning (i.e. when the message is
sent)  is correctly realized. I would agree that we have to work a little bit
on this specific point.

I don't like the idea of having packet store in the supervisor node because it
is somehow an hard state situation. the mobile node can not "resume" its
connection with another supervisor node. Our protocol allows this scheme as the
supervisor node does not store copies of messages when there is a link failure.

Vincent.

---

From: "James P. Salsman" <[email-masked]>
Date: Mon, 18 Sep 2000 20:08:26 -0700 (PDT)

Reiner,

Thanks for your reply:

>>...  There seems to be a lack of understanding about the

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
     Initial window        up to 4380B        RFC 2414 Experimental
     Use of SACK           Recommend          RFC 2018 Proposed Standard

So, given the ECN-like properties of Radio Link Control -- 3G TS 25.322; 
which also seems to be incorporated in current versions of GSM --
  http://webapp.etsi.org/action/OP/OP20000929/en_301349v080400o.pdf
-- is there really any need to add explicit link condition adaptation 
at the TCP or ICMP protocol levels?  I don't want to be in a position 
of advocating the change or addition of anything to those protocols 
unless absolutely necessary.

As far as robust wireless TCP goes, you are absolutely right that good 
service requires a maximum RTO shorter than the standard 64 seconds.  
What is that value in your TCP-Eiffel?

And one parameter that the DoCoMo draft doesn't mention (perhaps it 
goes without saying to most people) is a total retransmit timeout much 
longer than the typical 2-9 minutes.  Again, what do you use; an hour?

Cheers,
James

P.S. Please keep at least [email-masked] in on this, as the lack 
of ubiquitous wireless TCP is related to Mobile Multimedia Messaging 
applications.

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 19 Sep 2000 15:19:51 +0200

>      Feature        Parameter/Recommendation  RFC/Status

So PMTU discovery is the mechanism that should be used as it provides the 
largest MTU the path allows and that is really what we are after. Who 
knows, maybe (probably) in a few years MTUs larger than 1500B are more 
common. So, we should not recommend any fixed value like the 1500B just 
because that is the largest MTU found in the wide-area *today*.

But, really, this goes without saying. PMTU is a standards track RFC, so 
your TCP should have it, anyway.

>      Window size           64KB               RFC 793  Standard

I see that this is required for connections over some high bandwidth x 
delay links but I'm still not sure what the PILC group should recommend 
here. Should every OS allocate 64KB socket buffers by default? Probably 
not. Or should window scaling (RFC1323) be recommended?

>      Initial window        2 mss              RFC 2581 Proposed Standard

Goes without saying: it's a standards track RFC, so your TCP should have 
it, anyway.

>      Initial window        up to 4380B        RFC 2414 Experimental

Since this is an experimental RFC, this should better not be recommended at 
this stage.

>      Use of SACK           Recommend          RFC 2018 Proposed Standard

Goes without saying: it's a standards track RFC, so your TCP should have 
it, anyway.

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.

>So, given the ECN-like properties of Radio Link Control

What does that mean?

>at the TCP or ICMP protocol levels?

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.

>service requires a maximum RTO shorter than the standard 64 seconds.

I never said that. I do *not* want to change TCP's max. RTO.

I said that ***if*** your link layer is capable of separating TCP flows 
(more generally reliable flows including Reliable-Multicast, NFS, etc.) 
from other flows to avoid HOL blocking, ***then*** the link layer error 
recovery persistency for the TCP flows should be set to TCP's max. RTO, 
i.e., 64 seconds. That means that such a link layer sender will try for up 
to 64 seconds to successfully transmit a TCP packet. By the way, this helps 
you through some fairly hefty link outages.

***If***, on the other hand, your link layer is "transport blind", i.e., 
cannot separate flow types, ***then*** the error recovery persistency must 
be low (on the order of a second) again to avoid HOL blocking for delay 
sensitive flows.

>What is that value in your TCP-Eiffel?

It's TCP-Eifel (one 'f') ;-)

Although, TCP-Eifel implements a new retransmission timer that reacts 
quicker to packet losses than the standard timer, I have not changed the 
max. RTO.

>longer than the typical 2-9 minutes.  Again, what do you use; an hour?

TCP-Eifel implements a "retransmit forever" feature, i.e., ultimately the 
oldest outstanding packet is retransmitted every 64 seconds, until the 
application closes the connection. Currently this is only implemented as a 
compile option. Really it should be a socket option that the application 
could choose to enable or not.

Clearly, having TCP retransmit "forever" (read: until the application 
closes the connection) will be somewhat controversial ;-)

>of ubiquitous wireless TCP is related to Mobile Multimedia Messaging

I did it in this case but in general people interested in how these issues 
are discussed in the IETF should tune into the PILC mailing list.

///Reiner

---

From: "Injong Rhee" <[email-masked]>
Date: Wed, 20 Sep 2000 03:36:13 -0700

Agreed. Even the order of a second (or a few seconds) like current network
provides is still harmful for real-time flows like video streaming.
Currently we are experiencing more than 2 second delays on sprint pcs. Is
there any work addressing this delay issue?

>-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Reiner Ludwig
Sent: Tuesday, September 19, 2000 6:20 AM
To: James P. Salsman
Cc: [email-masked]; [email-masked]
Subject: Re: pilc minutes for IETF 48

.......[][]

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 20 Sep 2000 19:14:14 +0200

>linked to the wireless network?

No entity above the link layer needs to have access to link layer 
information to solve the problem of link outages. Please, check the 
reference to my thesis that I had sent in one of my last mails.

>of the link.

I don't think so.

>I don't like the idea of having packet store in the supervisor node

I wrote that packets are stored at the link layer sender.

>because it
>connection with another supervisor node.

I don't understand your notion of a supervisor node nor do I think that 
such a node is needed, assuming you mean that this node sits above the link 
layer. All that is needed is a plain old link layer protocol which of 
course is hard state.

///Reiner