Subject: Re: [tsvwg] [Technical Errata Reported] RFC3390 (4569)

From: Mark Allman <[email-masked]>
Date: Mon, 04 Jan 2016 14:49:18 -0500

Yep- this is a small error that could well be noted in the RFC
errata.

I looked at it has its roots in RFC 2414 (the RFC that 3390
obsoleted).  So, you might as well add a note to that one, too.

allman

> The following errata report has been submitted for RFC3390,
> "Increasing TCP's Initial Window".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569
> 
> --------------------------------------
> Type: Technical
> Reported by: Nikolai Malykh <[email-masked]>
> 
> Section: 8.1
> 
> Original Text
> -------------
>    A second set of experiments explored TCP performance over dialup
>    modem links.  In experiments over a 28.8 bps dialup channel [All97a,
>    AHO98], a four-segment initial window decreased the transfer time of
>    a 16KB file by roughly 10%, with no accompanying increase in the drop
>    rate.  A simulation study [RFC2416] investigated the effects of using
>    a larger initial window on a host connected by a slow modem link and
>    a router with a 3 packet buffer.  The study concluded that for the
>    scenario investigated, the use of larger initial windows was not
>    harmful to TCP performance.
> 
> Corrected Text
> --------------
>    A second set of experiments explored TCP performance over dialup
>    modem links.  In experiments over a 28.8 Kbps dialup channel [All97a,
>    AHO98], a four-segment initial window decreased the transfer time of
>    a 16KB file by roughly 10%, with no accompanying increase in the drop
>    rate.  A simulation study [RFC2416] investigated the effects of using
>    a larger initial window on a host connected by a slow modem link and
>    a router with a 3 packet buffer.  The study concluded that for the
>    scenario investigated, the use of larger initial windows was not
>    harmful to TCP performance.
> 
> Notes
> -----
> Error bit rate - bps instead of Kbps.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC3390 (draft-ietf-tsvwg-initwin-04)
> --------------------------------------
> Title: Increasing TCP's Initial Window
> Publication Date    : October 2002
> Author(s): M. Allman, S. Floyd, C. Partridge
> Category: PROPOSED STANDARD
> Source: Transport Area Working Group
> Area: Transport
> Stream: IETF
> Verifying Party     : IESG

---

From: Mitchell Erblich <[email-masked]>
Date: Mon, 4 Jan 2016 12:34:09 -0800

Mark Allman and group,

		As a later follow-up….

		Wouldn’t it make sense to mention that TCP’s Reno’s Fast Re-transmit” capability suggests that initial increases of  the initial window should generate earlier detection of congestion because of the non-wait of the coarse timeout ,, assuming that the number of Dup ACKs is adjusted accordingly?

		Mitchell Erblich

---

From: Mark Allman <[email-masked]>
Date: Mon, 04 Jan 2016 15:48:02 -0500

> 		Wouldn’t it make sense to mention that TCP’s Reno’s
> 		Fast Re-transmit” capability suggests that initial
> 		increases of  the initial window should generate
> 		earlier detection of congestion because of the
> 		non-wait of the coarse timeout ,, assuming that the
> 		number of Dup ACKs is adjusted accordingly? 

I am too old and have written too many words in my life to remember
precisely---and I don't have time to look---but presumably we said
something along these lines?  And, if not, it is more than an
errata, IMHO.

(There is nothing about adjusting the dup ACK threshold in 3390, I
am sure.  That is in RFC 5827.)

allman

---

From: Craig Partridge <[email-masked]>
Date: Mon, 4 Jan 2016 16:38:22 -0500

My view is errata is for technical nits that matter — not discussion or editorial improvement.

Speaking for myself (not as a member of the RFC Editorial Board).

Thanks!

Craig

> On Jan 4, 2016, at 3:48 PM, Mark Allman <[email-masked]> wrote:
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Jan 2016 11:50:08 -0800

> My view is errata is for technical nits that matter — not discussion or editorial improvement.

There are two types of errata - technical and editorial, as per:

https://www.rfc-editor.org/errata-definitions/

Both are to flag errors. Neither is intended to cache issues for
document updates or improvements. I've seen errata proposed that way,
but we really should push back on that practice.

Joe