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