Re: review solicitation for ICCRG congestion control survey

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

   

Wesley Eddy wrote:
> 
> 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 protected]).  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