Subject: TCP timeout parameters and wireless (was Re: pilc minutes for IETF 48)

From: "James P. Salsman" <[email-masked]>
Date: Tue, 19 Sep 2000 23:07:19 -0700 (PDT)

Mark,

Thank you for your message:

>... how does the end host figure out which situation (congestion 
> or outage) it is in? 

There are two end hosts.  Only one of them has a good chance of 
knowing, and the other doesn't usually care these days.

I agree that a well-designed signaling method (whether by TCP 
extensions or ICMP extensions) is a good idea, and I am sure 
that will be better-used in the future.

For now, though, in the situation most nets are in, if people 
want services that can be accessed reliably by wireless 
communications, they might want to at least lower their TCP 
maximum retransmition timeout values, consider lowering their 
RTO maximum, read Reiner's comments on the DoCoMo draft:

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

and have a look at his TCP-Eifel page:

  http://iceberg.cs.berkeley.edu/downloads/tcp-eifel

Now, I wonder which cellphone will be the first to play MIME
audio/mpeg attachments AND have PPP available on a DB-9 RS-232.

Cheers,
James

---

From: "James P. Salsman" <[email-masked]>
Date: Wed, 20 Sep 2000 15:11:07 -0700 (PDT)

Mark,

Thanks for your message:

>... It is my opinion that it is a mistake to reduce the maximum
> RTO too low....

Absolutly; I'm worried that even mentioning the RTO maximum will 
detract attention from the maximum retransmition timeout which is 
the REAL problem with TCP over wireless, more than all the other 
TCP parameters combined, certainly.

I mean, what difference does it make if you have to wait an extra 
minute to get a connection back as long as you can get it back 
instead of having it dropped after nine minutes?

Cheers,
James