[Iccrg] Delay as a metric of congestion

[John Leslie]

Matt Mathis <mathis at psc.edu> wrote:
> 
> John and I went around on this for a bit in a private conversation,
> where I argued against his position.

   I'm not positive what Matt "argued against," but it certainly wasn't
my "position"...

> However, Wes's comments about the history made me realize that I
> actually very strongly agree with a slightly weaker, conditional
> version of John's position.
> 
> Given that:
> 
> 1) When delay sensing works it generally provides better, more precise, 
> congestion control with less disruption to other applications than loss 
> based congestion control.

   I did not take that position, but I won't argue against it...

> 2) Delay sensing does not work in all environments and must be considered 
> to be an optimization that is conditionally applied in addition to the 
> primary loss based congestion control.

   I don't even agree with that...

> 3) For the vast majority of Internet users (e.g. home users behind a slow, 
> over buffered access link and perhaps wireless users) #1 applies extremely 
> strongly.

   I think Matt means that if we can determine that the bottleneck is
between the end-user and his/her ISP, delay is a better metric. I would
agree with that.
`
> Therefor: all stacks should include a secondary congestion control 
> mechanism that detects when they are causing large queues in the network 
> and regulates their congestion window accordingly.

   I couldn't agree with that exact wording, but Matt & I may be close
here. Perhaps:
" 
" Stacks intending to "play nice" with TCP should implement a delay-based
" mechanism to avoid reaching a congestion level where packets they send
" are dropped instead of delivered. Research into such methods is an
" appropriate field of study of the ICCRG.

> It may be an appropriate future work item of the ICCRG and IETF to
> attempt to standardize such a mechanism.

  I think in appropriate _now_ to collect data on how well delay-based
reductions (not necessarily multiplicative reductions) in window size
signal "gzornenplat" and avoid packets being dropped.

   ("gzornenplat" is a placeholder for what I actually wanted to talk
about: the onset of what I call "congestion", but not so much of it as
to require packets to be dropped.)

> In the short term it would be sufficient to merely agree on a statement
> of principle or intent.

   I really don't see how that would help...

   (Nor did I intend to talk of anything like this in my proposed
presentation...)

--
John Leslie <john at jlc.net>