Subject: [Tsvwg] draft-ietf-tsvwg-cc-alt-04.txt : Suggestion : Safe Operating zone

From: Erblichs <[email-masked]>
Date: Tue, 14 Aug 2007 15:29:35 -0700

Group, Sally Floyd, and Mark Allman,

	It seems that most CC algor have one common item
	which may be toooo generic, but I am going to
	suggest it here anyways..

	So, an additional checklist
	item within section "3. Guidelines" could be,,,

	(X) Plateau treatment of congestion levels

	A congestion control algorithm needs to identify and operate
	within safe plateaus, where the goal is to attempt to maximize
	(ie: bandwidth) and/or minimze (ie:delay) one or more operating 
	contraints. 

	The generic TCP implimentation operates within two coarse 
	plateaus: slow-start and congestion avoidance. The
	first plateau is normally quickly reached by coarse
	steps, while the second adds finer granularity.

	All congestion control algorithm MUST accept whether it actively
	transitions within both plateaus or operates only within
	one plateau. Quickstart is one CC algorithm that targets
	the first plateau.

	Mitchell Erblich

---

From: Mark Allman <[email-masked]>
Date: Wed, 15 Aug 2007 07:31:55 -0400

Mitchell-

Two things.

> 	(X) Plateau treatment of congestion levels

First, I read your proposed addition several times last night and this
morning and am not at all sure what you're trying to say.  It seems to
me that your text just says that there are going to be operating regions
for a congestion controller?  I don't quite understand how this is a
'guideline'.  What exactly would someone with an alternate congestion
controller do with this 'guideline'?  How would they address it?

Second, pragmatically this document is finished.  It has passed WGLC and
IESG review and is being processed by the RFC editor.  We could probably
stop the process if there was a show stopper, but this does not strike
me as even close to that.  I think at this point we're basically going
to have to live with the imperfections that remain in the document.  Of
course, if the WG wants to get itself in an uproar and agree with you
then we'd certainly do something.

allman

---

From: Erblichs <[email-masked]>
Date: Wed, 15 Aug 2007 10:10:12 -0700

Mark Allman, et al,

	First, I am glad that you read it. :^)

	With its Expiration date about 4 months
	from now, Dec, my assumption is that it was
	still "fermenting".

	After I read the document again, I didn't
	see how like CC are compared, because
	there were no characteristics for "likeness".

	Thus,,,

	It is a attempt to generalize and state that 
	ALL CC algorithms can be subdivided.

	The defacto-standard subdivision is at "threshold".

	Then LIKE CC algorithms could be compared to 
	a set of rules and against themselves.

	So, if we agree that QUICKSTART targets the first
	plateau (startup to threshold), any algorithm that 
	also targets targets the first plateau could be
	compared. One COULD then state a set of rules
	that targets that set of algorithms. And it would
	not make sense to compare any CA algor with
	QUICKSTART or generate one set of rules for both.

	Mitchell Erblich
	----------------

Mark Allman wrote:
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

---

From: Mark Allman <[email-masked]>
Date: Wed, 15 Aug 2007 13:30:57 -0400

> 	from now, Dec, my assumption is that it was

The expiration date in the draft (all drafts) is simply 6 months from
submission and it does not have anything to do with the process of
moving documents forward.  If you want to know the status of a draft you
need to follow along on the mailing list to see when it is advanced and
also you can look in the draft tracker
(https://datatracker.ietf.org/idtracker/) 

Two things.

First, I do not think our document was about comparing "like" things.
The goal of the document is not about trying to pick the best
alternative to help some facet of TCP's congestion control algorithms.
The goal of the draft is to help guide the process of making sure that
before we publish an RFC on some specific candidate scheme some minimum
amount of investigation has taken place to illuminate the impact the
alternate mechanism will have.

Second, I think you are asking for a level of detail that we were not
attempting to get into.  There is a bit of comparison in the document,
as far as relating the proposed scheme with the standard scheme.  It is
not clear to me that it is useful to say much beyond what we said.  This
document is a set of **guidelines**, not a **checklist**.  There is a
difference, with (IMHO) the latter being either very hard or
impossible.  If you think the IETF needs to specify a tighter list of
things that need to be done then I would suggest that you write up a
draft and see if there is consensus on it.

allman