[nwcrg] Fwd: [iccrg] Very fundamental congestion control questions...

FYI. This is a discussion a lot of us have had in the past.

mjm
Marie-Jose Montpetit, Ph.D.
mariejo@mit.edu
marie@mjmontpetit.com
+1-781-526-2661
@SocialTVMIT

> Begin forwarded message:
> 
> From: "Bless, Roland (TM)" <roland.bless@kit.edu>
> Subject: [iccrg] Very fundamental congestion control questions...
> Date: February 18, 2019 at 8:50:22 AM EST
> To: "iccrg@irtf.org" <iccrg@irtf.org>
> 
> Hi all,
> 
> I think I can second Keith Winstein's statement
> "we lack a real understanding and common language about
> some of the fundamental concepts and hard parts..."
> (https://mailarchive.ietf.org/arch/msg/iccrg/LHRAWIjbFktaqLC5hFqgG37M9zk)
> and want to open a
> new discussion thread for this.
> 
> One of the problems that we have is (IMHO), that there
> is currently no commonly agreed definition of what
> _congestion_ is actually. So every congestion control
> developing people should at least have clear answers
> for themselves to these questions:
> 
> 1) what is congestion (or congestion situation)?
> 
> 2) how to detect a congestion situation
>   (or even severity levels of congestion)?
> 
> 3) how to react on a detected congestion situation?
> 
> Letting the related fairness discussion aside, I think that even
> RFCs do not give a clear definition of what congestion is and
> the views, Internet usage, and requirements have considerably
> changed over time.
> 
> So in former times, the term congestion was mainly
> driven by the congestion collapse experience.
> Consequently, most RFCs refer to the prevention of
> that congestion collapse when discussion congestion control
> (or congestion avoidance), e.g., RFC 7567:
> "It is primarily these TCP congestion avoidance
> algorithms that prevent the congestion collapse of today's Internet."
> 
> Nowadays, the interest has probably shifted towards
> systematically reducing queueing delay and congestion could
> be seen as being related to the level of waiting time in
> bottleneck queues (this would also allow for the definition
> of different levels of congestion).
> 
> While the analogy to ordinary car traffic scenarios is not always
> right, in this case I find it useful: you do not consider the
> waiting time in front of traffic lights as congestion
> unless you are waiting more than x min in addition
> to what you normally experience during non-congested
> times (e.g., waiting two traffic light phases is probably
> considered being okay, but more than that may be already
> viewed as being traffic congestion).
> However, both traffic broadcast and navigation systems
> nowadays announce congestion by indication of expected
> additional waiting/queueing time (which is more useful than
> just mentioning the length of the congestion in kilometers).
> In this regard, I would heavily recommend to reread
> Kathie's and Van's "Controlling Queue Delay" Paper:
> https://queue.acm.org/detail.cfm?id=2209336
> and the introduction of good/bad queues, standing queues,
> and sojourn times, which could be quite helpful in the
> congestion definition discussion.
> 
> Similarly, the answer to 2) should not be "packet loss"
> alone anymore, but probably trying to distinguish
> between congestion induced packet loss and short-term (burst)
> loss that is not caused by a real congestion situation.
> So in lack of ECN or other explicit congestion signals,
> multiple measured parameters may be combined for better
> congestion detection than relying on packet loss alone.
> 
> I think it could be useful to discuss a bit along
> the above listed questions in order to move CC research
> forward by probably achieving a better understanding and
> common language about the fundamental concepts... :-)
> 
> Regards
> Roland
> 
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg