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

[Joe Touch <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg