Subject: Re: Reminder: WG last call for ERROR

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2000 15:05:10 +0100

Reiner Ludwig wrote:

> At 11:58 31.08.00 -0400, Falk, Aaron wrote:
> >Working group last call is coming to an end for ERROR. Spencer will be
> >following up with a summary of comments/changes for the draft before we
> >submit it to the IESG.
> ...
> Some comments:
>
> - Page 7 / 1st para:
> "... constantly closing 'trained' TCP connections ... . This is true even
> with HTTP1.1 ..."
> I don't understand this last sentence. HTTP1.1 is *not* constantly closing
> 'trained' TCP connections. It might do so after some idle time (RTO)
> though. Is that was it meant?

 I took the phrase "This is true even with HTTP1.1 in spite of its support
for persistent connections." to mean that persistence is part of 1.1, but is
not often (as yet) widely used.

However, the above comments perhaps suggest another possible interpretation
is that the window information should be aged when the session becomes idle
and that therefore a pause in the application transfer, causes the available
window to reduce.

I think both are valid - perhaps it should be clarified?

Gorry

P.S.
Page 6 sect 2.1, - During Slow Start

Note that a small MTU is not of benefit to a less-reliable link,
unless Path-MTU discovery is used.  If it is not, the smaller MTU
will result in IP fragmentation - increasing the data being sent, and
does not decrease the unit of retransmission - hence it reduces
throughput. With PMTU it helps.  (Transparent fragmentation
by the link layer is an all together better mechanism if link ARQ is used.)

Page 10 sect 4.0, - para 3.

Appropriate byte counting is just one option to reduce burstiness
caused by missing ACK packets - there are others!
e.g. ACK rate control within the network, TCP transmit pacing at
the sender.

------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 4 Sep 2000 15:36:56 +0100 (BST)

> Note that a small MTU is not of benefit to a less-reliable link,
                   ^link
> unless Path-MTU discovery is used.  If it is not, the smaller MTU
                                                               ^link
> by the link layer is an all together better mechanism if link ARQ is used.)

I think 'link MTU' needs to be explicitly mentioned here for clarity;
the first time I read Gorry's paragraph I did a double take, saying
'no, it's a _larger_ (path) MTU that leads to IP fragmentation!'

L.

that and IPSec encapsulation, whose added header tends to break the
assumptions in MTU implementations.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2000 15:05:10 +0100

Gorry

P.S.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 4 Sep 2000 15:36:56 +0100 (BST)

^link
                                                               ^link

L.