ietf
[Top] [All Lists]

Re: pilc minutes for IETF 48

2000-09-18 03:10:02
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



<Prev in Thread] Current Thread [Next in Thread>