Re: pilc minutes for IETF 48

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

Received on Monday, 18 September 2000 05:48:42 UTC