Re: [Tsvwg] Re: HighSpeed TCP for Large Congestion Windows

[Sally Floyd <[e-mail]>]

>My read was somewhat different. While some were interested in exploring 
>this (IMO, 'academically'), most felt that because it wasn't of 
>near-term utility it was premature for the WG.

>My own thoughts, as mentioned at the IETF, are that there are 
>interesting aspects to this, but I'm uncomfortable with proposing three 
>modifications at once. That either means there's a more fundamental 
>problem, or that some of the solutions are marginal, or both.

I think that there are two completely separate fundamental problems.
One is that the current TCP response function requires unrealistically
low packet drop rates to sustain congestion windows of thousands
or tens of thousands of packets.  The second fundamental problem
is that if best-effort connections want to *start* with large
windows, then they need explicit permission from all of the
routers along the path (in my view).

I think these are separate problems, with completely separate time
scales, as I thought I made clear in my presentation.  That is, it
would make sense to me for the HighSpeed TCP draft to be mulled
over and then, in the fullness of time, if it is judged by the
community not to be unduly dangerous and/or unfair, to become an
Experimental RFC, so that more real-world experience can be gathered.

The Limited Slow-Start draft is a small, completely optional proposal
that, in my view, is useful to allow TCP connections to effectively
slow-start up to those very large congestion windows.   It is a
separate draft from the HighSpeed draft, however, because it could
be useful with or without the modified response function of HighSpeed
TCP.  Just a small piece that, in a reasonably simple and low-overhead
way, addresses some of the real-world problems of slow-starting up
to large windows.  In my view.

(I have new versions (with rather small modifications) of both of
these drafts on the HighSpeed TCP web page at
"http://www.icir.org/floyd/hstcp.html", though they have not yet
been submitted to the internet-draft editor.  As always, feedback
is welcome.


The second fundamental issue, of how to get permission from routers
for best-effort (or other) traffic to start with a high initial
window, is in my view quite separate, more long-term (as is
anything involving modifications to routers) and more controversial.
I am assuming that the QuickStart draft, which presents one proposal
addressing this fundamental issue, will take a completely different
path from the HighSpeed and Limited Slow-Start drafts (if it ends
up taking any path at all).  That is, I am assuming that any path
for this would be properly slow and torturous, with separate
problem statements, comparisons of other proposals, and the whole bit.
That is why it makes sense to be to begin to raise the issue now,
rather than waiting until it is a more pressing concern.  (Because
we are still going through this with ECN, I am reasonably aware of how 
long these things can take.)


Of course, it is possible to propose unified approaches, involving
feedback from the routers, that address both fundamental issues.
My own view is that there is no *requirement* to bundle the two
issues together.  Further, I think there is great value in addressing
the first issue, of the unrealistically low packet drop rates
required to sustain large congestion windows, in a manner that can be
quickly and easily incrementally deployed in the current environment
only with a small change to the TCP sender, with no changes required
at the routers or at the TCP receiver at all.  I would go further
to say that I think that it is *fundamentally correct* to address the
first issue on this level, as the first-order correct answer in
fact doesn't have anything to do with feedback from the routers one
way or another.  That is, in my view, the problem of TCP's requirement
for unrealistically low packet drop rates to sustain large congestion
windows is easy to fix, and does not stem from any fundamental
problems with the current available feedback from the routers.


>FWIW, regarding using an IP option to optimistically reserve router 
>resources. We already have a mechanism for this - RSVP. It might be 
>useful to explore encapsulating a TCP SYN inside RSVP, where the routers 
>keep only temporary aggregate state about the reservation (total 
>allocated over the past 1 second) and the endpoints decapsulate and pass 
>the request onto the host.

Interesting.  Though I would think that the IP option would be a
better fit for Quick-Start, because Quick-Start isn't using any
soft-state refreshing, or asking the router to maintain any per-flow
state at all.

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


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