Subject: Reminder: WG last call for ERROR

From: "Falk, Aaron" <[email-masked]>
Date: Thu, 31 Aug 2000 11:58:40 -0400

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. If there are any further comments, now is the time.

--aaron

> -----Original Message-----
> From: Falk, Aaron [mailto:[email-masked]]
> Sent: Monday, August 14, 2000 10:23 AM
> To: [email-masked]'
> Cc: Spencer Dawkins (E-mail); [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: WG last call for ERROR
> 
> 
> The document "End-to-end Performance Implications of Links 
> with Errors" is
> ready for working group last call. Please send comments to 
> the PILC mail
> list. 
> 
> A current version of the draft can be obtained from
> http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-04.txt
> 
>

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 01 Sep 2000 00:14:19 +0200

At 11:58 31.08.00 -0400, Falk, Aaron wrote:
>submit it to the IESG.

Asking the IESG for what? Informational RFC?

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?

- Page 7 / last para:
"In low-speed, ... (e.g., wireless WAN ...), TCP windows are much smaller, ..."
This is often *not* the case. E.g., if the mobile client is sending and its 
interface buffer has default size (e.g., 50 packets in FreeBSD). This 
allows for lots of queueing and the sending TCP will reach the advertized 
window. We observed this, e.g., in one of our studies 
http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/index.html

- Why do we need the appendices? Do they add to the document when nothing 
of it is recommended?

- Page 16 / 1st para:
The Eifel algorithm makes *no* assumption about any link layer. It's a 
general mechanism that makes TCP more robust in the face of spurious 
timeouts and packet re-orderings, no matter what the reasons are that 
caused those events.

///Reiner