Subject: Last Call for SLOW draft ends this coming Friday

From: Spencer Dawkins <[email-masked]>
Date: Tue, 16 Jan 2001 06:59:51 -0800 (PST)

Please forward any comments you have to the mailing
list.

Thanks,

Spencer

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 18 Jan 2001 17:44:19 +0200 (EET)

Please find some comments on draft-ietf-pilc-slow-05.txt below:

>2.3 Choosing MTU Sizes

- in case the last-hop router's queue is in terms of packets, not bytes
having a larger MTU can decrease amount of buffer overflows (and thus
amount of congestion losses)

-larger MTU causes larger RTT that in turn increases RTO value. In case of
an error burst RTO is backed off to a large value (this is relevant on
link with errors)

-if charging (e.g. in GPRS network) is based on the number of transmitted
packets, not bytes, the user may want to use larger MTU

-when error losses on the link are in terms of packet-based probability
(not BER) larger MTU is beneficial (this is relevant on link with errors)

> 2.4 Interactions with TCP Congestion Control

- the slow-start overshoot causes plenty of congestion losses in the
last-hop router

-our experiments suggest last-hop buffer size of 3-12 as optimal for bulk
TCP connections

-RED in the last-hop router may not be useful. First, a completely
different set of algorithm's parameters is needed than normally used in
backbone routers, those parameters are difficult to estimate. In addition,
we saw none or little improvement experimenting with one or two bulk TCP
connections over RED in the last-hop router. In opposite, using a wrong 
parameter values easily decreased performance.

> Hosts that are directly connected to low-speed links may
>   limit the receive windows they advertise in order to lower or
>   eliminate the number of packet drops in a last-hop router.

- we experimented with different sizes of receiver window. Too
small window (e.g. less than 8*MTU) can hamper TCP loss recovery

-there is a more general problem of overbuffering in slow links that was
described for example by Reiner and related problems (e.g. very long
recovery time due to inflated RTO).

for details see my thesis at
http://www.cs.Helsinki.FI/research/iwtcp/papers/

Andrei