Re: [Tsvwg] High-speed TCP

[Sally Floyd <[e-mail]>]

>>   The proposals in this document are experimental.  We believe they
>>   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.

The same argument could have been made about NewReno TCP, which has
been Experimental since January 1999.  That is, there are scenarios
where NewReno TCP receives a disproportionate share of a link if
competing with then-conventional Reno TCP, in scenarios where loss
events are likely to consist of multiple packets dropped from a
window of data (e.g., in networks with Drop Tail queue management).
This is due to Reno TCP's often abysmal performance when multiple
packets are dropped from a window of data.  The rough consensus at
the time, as I recall, was that NewReno was considered safe for
deployment in the current Internet even though NewReno flows might
receive a disproportionate share of a link if competing with Reno,
because we didn't want the limitations of Reno TCP to become
preserved in the Internet in perpetuity.  I would suggest that a
similar situation occurs with HighSpeed TCP.

The internet draft about HighSpeed TCP is quite explicit about
the issue of relative fairness with Standard TCP, and it is not
the case the HighSpeed TCP will always receive a disproportionate
share of the link bandwidth when competing with Standard TCP.
In the environments where Standard TCP is clearly capable of
making good use of the existing link bandwidth, e.g., with 
packet drop rates of 10^-2 or 10^-3, HighSpeed TCP does exactly
the same thing as Standard TCP.  Table 5 of the draft shows
how the relative fairness goes in environments with smaller 
packet drop rates:

      Packet Drop Rate P   Fairness  Aggregate Window  Bandwidth
      ------------------   --------  ----------------  ---------
             10^-2            1.0              24        2.8 Mbps
             10^-3            1.0              76        9.1 Mbps
             10^-4            2.2             383       45.9 Mbps
             10^-5            4.7            2174      260.8 Mbps
             10^-6           10.2           13479        1.6 Gbps
             10^-7           22.1           87776       10.5 Gbps

    Table 5: Relative Fairness between the HighSpeed and Standard
    Response Functions.

The arguments of the draft are that the relative fairness of
2.2 with packet drop rates of 10^-4 are not a grave concern, and
that for the lower-packet-drop-rate environments with the more severe
unfairness, Standard TCP doesn't do very well at making use of the
available bandwidth.  From the draft:

"Our judgement would be that ... the benefits of the HighSpeed
response function would outweigh the unfairness that would be
experienced by Standard TCP in this regime."

But this is being brought to the working group for the group to decide.

From later email:
>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.

I don't believe this.  Do you have any simulations or experiments
to back this up?  If a HighSpeed TCP and a Standard TCP were competing
over a congested shared link, and the Standard TCP was over a short
fast path, the Standard TCP would induce a rather high packet drop
rate in the shared link, and the HighSpeed TCP would be in the space
where it behaves roughly the same as Standard TCP.

...
>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).

Again, if a long-RTT HighSpeed TCP is competing over a congested
link with a Standard TCP flow that has a small window and a short
RTT, the advantage is more likely to go to the Standard TCP short-RTT
flow.  As is normally the case when short-RTT TCP flows compete
against longer-RTT flows.

...
>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.

Personally, I think that HighSpeed TCP is perfectly safe to be
deployed on by default, for anyone/implementor who so chooses.  
(My own view is that HighSpeed TCP goes to great lengths to position
itself on the conservative, incrementally-deployable end of the
spectrum.  And that HighSpeed TCP is *more* safe than the N parallel
TCP connections that are often deployed in fact in its place, in
the current Internet in environments where Standard TCP is not up to
making good use of the available bandwidth.) 

But the decision rests with the working group as a whole...

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

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