Subject: [Tsvwg] review solicitation for ICCRG congestion control survey

From: Wesley Eddy <[email-masked]>
Date: Thu, 11 Jan 2007 10:55:41 -0500

In the ICCRG's goal to foster a long-term congestion control
architecture for the Internet, its initial step is to understand all of
the current mechanisms in use.  As an aid to this, the ICCRG is working
on a document that summarizes all of the congestion control mechanisms
and other guidance that the IETF has produced and published in the RFC
series.  The initial version of this document is online:
http://tools.ietf.org/group/irtf/draft-irtf-iccrg-cc-rfcs-00.txt

We think this is a fairly complete listing of the RFCs that relate to
congestion control, but if you know of others that should be included,
we would like to hear about it.

Also, comments on what can be done to make this more useful or readable
are welcome.  Comments on and improvements to the text summarizing each
RFC are also welcome.

The goal is to gather these inputs before the ICCRG meeting in
mid-February.  After the ICCRG meeting, the document will be updated
based on these comments and discussion from the meeting.

Please send all comments to the ICCRG list ([email-masked]).  Although
this request is being sent to multiple lists, this is only to notify
people not on the ICCRG list; we do not want to burden the other mailing
lists with replies, so please trim the "to" and "cc" fields of replies.

Thanks in advance.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: Erblichs <[email-masked]>
Date: Thu, 11 Jan 2007 16:05:49 -0800

To the world,

	Doesn't this document initially imply that ONLY
   "feedback-based adjustment" type responses are available 
   to ameloriate congestion.

    As congestion approaches, the lack of acks/feedback can
   also indicate congestion. So I would first modify section
   "1" to indicate that the loss of feedback is also a level
   of feedback that needs to be considered.

   IMO, in full congestion collapse with a significant number
   of non congestion aware flows, any adjustment of congestion
   aware flows would not effect the overall congested environment.

   Thus, most if not all congestion avoidance algorithms assume
   that congestion can be altered by the aware flows. This document
   needs to be cognizant of that fact and state that no algorithm
   would be successful in any congestion event that is controlled
   by unaware flows.

   Thus, to guarantee a congestion collapse free "area/AS"  or
   minimize the amount of congestion, the bandwidth consumption 
   needs to be controlled. It can be controlled at either the 
   entry to the area/AS by a transit flow or controlled at the
   src end point. Doing neither ameliorates any effect of any
   congestion control algorithm.

   Thus, this document mostly covers the investigaion of "area/ASs"
   where congestion is a concern and what has been proposed to
   minimize the effects of congestion.

   In addition, this reader is unaware whether this document prefers
   flows that are at the precipice of congestion or whether a
   significant buffer of lost bandwidth should be used to minimize
   any congestion type behaviours.

   Lastly, IMO a general concensus needs to be developed to determine
what
   are the initial measured indications of congestion. The general TCP
   method is the loss of a pkt/segment. Should it be increased RTTs due
   to longer queues? Or should it be the combination of the two? Is
   a time aware (real-time) flow in congestion if required parameters
   are exceeded? etc..

   Mitchell Erblich
	===========

---

From: Erblichs <[email-masked]>
Date: Fri, 12 Jan 2007 12:45:30 -0800

Authors,

	Layout/per RFC question,

	Can I suggest a different per RFC layout.
        In my opinion, each RFC listing item should include the type of
RFC,
        the date, the first author, and then the abstract. To give a
        different summary than the abstract is inconsistent to what was
        initially published for the RFC and may change the meaning of
	the abstract than what the authors intended.

	If the abstract is missing, then I could agree that a substitute
	description be given in this doc. If the abstract is "too long"
	or missing, I would think that a shortened version in this
	document with a preword that this doc may contain a shortened 
	abstract, new, or different of the mentioned of the RFC and that 
	has been approved by the RFC authors.

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