Subject: [Tsvwg] High-speed TCP

From: Mark Handley <[email-masked]>
Date: Fri, 18 Jul 2003 10:32:29 +0100

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.  

Cheers,
	Mark

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

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 18 Jul 2003 14:48:13 +0200

>   with such alternative proposals.

I think this is good proposal, and I support it.

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"?

Concrete example: Is the IETF recommending the deployment of the many 
TCP-related experimental RFCs (that don't have an explicit recommendation 
for deployment), or not?

I tried to find the answer in RFC2026, but wasn't quite clear. Also, I hear 
that the standards track definition of RFC2026 might not be current IETF 
believe anymore. See also draft-dawkins-pstmt-twostage-00.txt ...

///Reiner

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 21 Jul 2003 18:46:42 -0500

Dear Reiner,

I'm honored that someone has tripped over our proposal, but it's
just a proposal! I can say that there's some interest in looking at
the standards levels - Scott Bradner is also looking at this -
but 2026 is 2026 for now...

... and feedback is always welcome ...

Spencer

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Jul 2003 13:41:22 -0700

Mark Handley wrote:
>   are safe for deployment in the current Internet,

Why is this believed? The document states fairly clearly that this sort 
of TCP will receive a disproportionate share of a link if competing with 
conventional TCP.

So far, the discussion seems to qualify 'safe' as 'safe in a closed 
environment' or 'safe if used primarily over very high speed links'. 
That's not particularly 'safe', since these criteria are external to the 
protocol.

Joe

---

From: Mark Handley <[email-masked]>
Date: Wed, 23 Jul 2003 22:06:03 +0100

>of TCP will receive a disproportionate share of a link if competing with 

Two points:

 - this was my suggested text, sent to the list for critique.
 - the opinion represented the consensus in the room at the IETF.

Personally I feel it's "safe" in the sense that it will achieve a
disproportionate share only under circumstances under which a
conventional TCP is unable to effectively use the available bandwidth.

But I'm not one of the main advocates of this particular draft, so I'm
not the person to convince otherwise.

Cheers,
	Mark

---

From: Matt Mathis <[email-masked]>
Date: Wed, 23 Jul 2003 17:47:29 -0400 (EDT)

There is general agreement that at very large windows (e.g. more than 1000 
packets in flight) TCP is way too sensitive to packet loss, making it 
unreasonably difficult to get line rate on long fast networks.

Fixing this excessive sensitivity to loss intrinsically requires redefining TCP 
friendly.  It is universally understood that during any such transition there 
are likely to be situations where new TCP and old TCP do not play as nicely as 
one would hope.   In the case of Sally's High-speed TCP, we understand the 
likely worse case bound on the unfairness.  In reality, stock TCP does so 
poorly in most of these situations that "fairness" isn't even the point....

The real question that the WG discussed had to do with the possibility of a
partial interim deployment of Sally's HS-TCP causing deployment problems for a
future algorithm, such as XCP or FAST.  Note the real question is not if the
protocols play nicely, but if the users will play nicely.

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 discussion (and hummed consensus) at the WG was about balancing the value 
of an interim solution and various risks.   Most of the worry seemed to be 
about risk to a future right answer, and not about current TCP.   In any case 
the hums were not even close.

Good enough?

Thanks,
--MM--

-- 
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Jul 2003 16:21:30 -0700

> poorly in most of these situations that "fairness" isn't even the point....

There are cases where it is possible that stock TCP is used over short 
fast links and this would be needed for longer paths. Using both on the 
same enterprise could cause significant unfairness, in ways that are not 
considered a reasonable interim step.

> HS-TCP might have an unfair advantage over the_right_answer....

As above, using this protocol over a HS-path might interact very badly 
with other streams that share part but not all of the path, e.g., 
conventional TCP at high speeds near the endpoints (which have a small 
window and no need for this sol'n).

> the hums were not even close.

I'd be more comfortable with a statement that doesn't so broadly endorse 
experimenting with it on the Internet as a whole without some caveats, 
notably those which appear to be implied.

I.e.,
	- off by default
	- turned on only on applicable paths or environments
	- it is the responsibility of those using this protocol to
	determine whether it is affecting others, and when such effects
	are found, to disable it until they can be corrected

These may be implicit in the concept of 'experimental', but if we're 
saying it's 'safe', it ought to be clear about under what conditions.

Joe