Subject: Re: [Tsvwg] High-speed TCP

From: Sally Floyd <[email-masked]>
Date: Mon, 21 Jul 2003 11:48:31 -0700

>Just one question: Could anybody, please, explain to me the difference 
>between an "experimental RFC with a recommendation for deployment (with or 
>without a boilerplate about warnings)" and a "proposed standard RFC"?

Actually, my request is not for High-speed TCP to be considered as
an experimental RFC with a recommendation for deployment, but as
an experimental RFC that is judged as safe for deployment, that is,
that someone could deploy (in their own computer, or in their
widely-distributed commercial TCP distribution) *if they wanted
to*.  My own view would be that the likely audience for such
high-congestion-window variants of TCP is small, at the moment, and
that for most TCP users it wouldn't make much different one way or
another whether they used Standard or HighSpeed TCP.

This would have the same formal status of NewReno TCP, RFC 2582,
April 1999, which is also Experimental.  At the time, in 1999, my
memory is that people wanted more operational experience with NewReno
before considering it for Proposed Standard (and at the time, I
thought that there might also be other proposals for NewReno-type
variants of TCP, for those cases where the other end was not
SACK-capable, that would also be Experimental).  It seems plausible
to me that some major changes to TCP pass thought a period of
Experimental before moving on the Proposed Standard, giving the
role of TCP in the Internet.

- Sally
http://www.icir.org/floyd/

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Sally Floyd <[email-masked]>
Date: Mon, 21 Jul 2003 12:17:13 -0700

>In followup to today's TSVWG meeting, here's some suggested
>boilerplate text for the High-speed TCP Experimental RFC:
>
>  The proposals in this document are experimental.  We believe they
>  are safe for deployment in the current Internet, but they do not
>  represent a consensus that this is the best method for high-speed
>  congestion control.  In particular, we note that alternative
>  experimental proposals are likely to be forthcoming, and it is not
>  well understood how the proposals in this document will interact
>  with such alternative proposals.  

That sounds good to me, and I will include it in a revised version
that I submit later this week.  

The only other thing in the revision will be a paragraph later in
the document saying that I don't expect HighSpeed TCP to interact
any more poorly with alternative experimental proposals that would
the N parallel TCP connections commonly used today in the absence
of HighSpeed TCP.  That is, I don't believe that a deployment of
HighSpeed TCP would present any block to the later deployment of
Scalable TCP, FAST TCP, XCP, or any of the other alternative
experimental proposals.

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Thu, 24 Jul 2003 15:06:21 -0700

>It would be a_very_bad_thing if HS-TCP proved to be very unfair to
>the_right_answer(TM) and at the same time came to be in wide use by innocent
>users (say because some large vendor shipped it turned on by default).
>
>As long as HS-TCP is off by default, it will require a certain level of user
>awareness to turn it on.  Such users are likely to be aware of the_right_answer
>when it becomes available.  Just a moderate level of education will be
>sufficient to prevent chronic problems in the (presumably small) regime where
>HS-TCP might have an unfair advantage over the_right_answer....

The added text in the revised version of the draft,
draft-ietf-tsvwg-highspeed-00.txt, is as follows:

    We do not believe that the deployment of HighSpeed TCP would serve
    as a block to the possible deployment of alternate experimental
    protocols for high-speed congestion control, such as Scalable TCP,
    XCP [KHR02], or FAST TCP [JWL03].  In particular, we don't expect
    HighSpeed TCP to interact any more poorly with alternative
    experimental proposals that would the N parallel TCP connections
    commonly used today in the absence of HighSpeed TCP.

I would personally expect HighSpeed TCP to interact considerably
*better* with any alternate experimental protocol that would the 
N parallel Standard TCP connections that are in fact deployed in its
place, for some arbitrary value of N. 

(And hopefully HighSpeed TCP would do sufficiently well at making
use of the available bandwidth that people wouldn't feel the need,
or the justification, to use N parallel HighSpeed TCP connections
as a regular thing, for large N.  Or maybe we will manage at some
point to get mechanisms in routers that can take care of such
issues, who knows?)

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Fri, 25 Jul 2003 08:44:54 -0700

The modified version of draft-floyd-tcp-highspeed-03.txt, now called
draft-ietf-tsvwg-highspeed-00.txt, has already appeared in the
internet-drafts repository, but I have posted a file with the list
of changes to make at:
  http://www.icir.org/floyd/hstcp/draft-ietf-tsvwg-highspeed-00.errata

The contents are given below.

- Sally

-----------------------------------------------------------------------
http://www.icir.org/floyd/hstcp/draft-ietf-tsvwg-highspeed-00.errata:
-----------------------------------------------------------------------

Changes to make to draft-ietf-tsvwg-highspeed-00.txt:

Change:

"The proposals in this document are experimental.  We believe they
are safe for deployment in the current Internet, "

To:

"The proposals in this document are experimental.  While they may be
deployed in the current Internet, "