Re: [Tsvwg] High-speed TCP

>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
http://www.icir.org/floyd/

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg