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

From: Joe Touch <[email-masked]>
Date: Thu, 01 Aug 2002 11:20:56 -0700

Sally Floyd wrote:
>>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.

Limited Slow-Start is related to QuickStart, IMO. Both are methods, 
albeit with different mechanisms, for rapid ramp-up.

[Limited Slow-Start]
 > is a
> separate draft from the HighSpeed draft, however, because it could
> be useful with or without the modified response function of HighSpeed
> TCP.

It is not useful to be able to ramp up to a large window that cannot be 
sustained. These are necessarily related.

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

The need for collaborative engineering work is not the same, IMO, as 
having this be part of the WG. The WG should focus, IMO again, on items 
which can be moved within 6-9 months to RFC. These all seem like ongoing 
research which is of interest to the members of the WG, and might be 
useful to discuss on this mailing list, but are not yet productive WG 
agenda items.

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

There may be two issues, rather than three, or one. However, even the 
one less controversial - how to sustain window size during reasonable 
drops - is already itself a variant of fast retransmit, IMO. The idea of 
both being to avoid slamming the window needlessly. It would be useful 
to find a unifying mechanism rather than 'yet another variant'.

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

Communicating to resources at the router, IMO, is the domain of RSVP, 
not IP. RSVP contains a soft-state mechanism and maintains per-flow 
state, but neither should be necessarily required. If we're modifying 
protocols, let's modify the right one - RSVP, IMO, again.

Joe

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

---

From: Sally Floyd <[email-masked]>
Date: Thu, 01 Aug 2002 11:05:31 -0700

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.

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.

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

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 09 Aug 2002 11:28:07 +0200

Hi Sally,

At 20:05 01.08.2002, Sally Floyd wrote:
>or tens of thousands of packets.

I'm convinced that TCP has a (fundamental) problem if it has to operate 
with a congestion window of thousands or tens of thousands of packets. But 
I'm not convinced that this is a *real world* problem.

Which *real world* applications ever drive a TCP sender into such a regime?

Such applications would have to move *terra* bytes *back-to-back* to start 
having that problem. I'm not convinced that such applications are running 
on the *public* Internet today or in the foreseeable future. Please, 
convince me if you think otherwise.

Even if members of the IP Storage WG are talking about moving large pieces 
of data, are they really moving *terra* bytes *back-to-back*? Sending only 
a few 10 Gigabytes every now and then is a different story.

As it stands, it seems that the ID describes a solution for a problem that 
nobody has today or will could have tomorrow. Also, my understanding is 
that IETF WGs only deal with *real world* problems, and that the more 
academic problems are dealt with in the research community.

///Reiner