Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

["Black, David" <[e-mail]>]

I wrote: 

>> Another possible rationale for this mixing is that if drops start occurring, then many of
>> the new and proposed uses of ECN that treat ECN-CE marks as less than loss-equivalent
>> are outside their intended operating envelopes/regions.

Colin responded:

> Clearly if the queue has been driven to overflow, so that packet loss is
> occurring, then the AQM is outside its intended operating regime. I’m not sure
> we need to push it so far, though. Is there not a regime where the ECN-CE
> marking rate indicates excessive congestion, before the queue overflows and
> drops packets?

Yes, but that may not be relevant to this discussion.   My hypothesis for this discussion
is that actual drops will occur well before RTP  is running at 10x the TCP equivalent rate
(based on drops and ECN-CE marks), and that 10x factor is the trip threshold for the
circuit breaker, which is the focus of this discussion. 

I would think that the "regime where the ECN-CE marking rate indicates excessive
congestion, before the queue overflows and drops packets?" would not extend as
far as RTP running at 10x the TCP equivalent rate, which is where the RTP circuit
breaker trips.

This is all a thought exercise - I'm happy to be shown to be wrong based on actual
data and experience with "running code" ...

To which Michael responded: 

> Shouldn’t a congestion control mechanism react well before that?

Yes, if there is one ;-).  This is RTP ...

Thanks, --David

> -----Original Message-----
> From: Michael Welzl [mailto:[e-mail]]
> Sent: Wednesday, June 29, 2016 4:55 AM
> To: Colin Perkins
> Cc: Black, David; [e-mail]; tsvwg; IETF AVTCore WG
> Subject: Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-
> avtcore-rtp-circuit-breakers-16
> 
> 
> > On 29. jun. 2016, at 00.02, Colin Perkins <[e-mail]> wrote:
> >
> >
> >> On 28 Jun 2016, at 02:04, Black, David <[e-mail]> wrote:
> >>
> >> Trying to shorten up this thread again ...
> >>
> >>>>>> I'm not quite sure how to specify "use of ECN as additional evidence" of
> >>>>>> "excessive congestion" as drop-equivalence is about the best we have
> >>>>>> for current guidance.
> >>>>>
> >>>>> I fail to parse that sentence, so maybe I’m getting you wrong, but anyway
> I
> >>>>> wonder: what’s even the point of this?
> >>>>> Why even bother considering CE-marks as information for a circuit
> breaker?
> >>>>
> >>>> Because the alternative is that we only break the circuit once the queue has
> >>> been driven into overflow, and packets have been lost. We want to avoid
> that,
> >>> since it causes latency, and too much latency is very bad for the user
> experience.
> >>>
> >>> Well - the better way out would be for the application to react. Maybe this is
> me
> >>> misunderstanding the circuit breaker, but I did think it’s more like a last
> resort…
> >>> you just don’t want to be trigger-happy with such a thing?
> >>
> >> Well, the RTP circuit breaker draft is not trigger happy - for its congestion
> circuit
> >> breaker to trip, RTP has to be sending at 10x the rate that TCP would send
> under
> >> those conditions, based on the TCP throughput equation.  See:
> >>
> >> https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16#section-
> 4.3
> >>
> >> The issue here is - when calculating the comparable TCP throughput, how are
> ECN-CE
> >> marks used to determine the loss rate input to the TCP throughput equation?
> Do
> >> ECN-CE marked packets count as having arrived or having been dropped?
> >
> > Right - or do they count somewhere between the two.
> 
> Let’s see them clearly for what they are.
> They mean: the path is *not* broken (they have arrived!), and a probably an
> AQM mechanism, potentially using a shallow queue, marked them to indicate
> congestion. I think “somewhere between the two” really doesn’t capture this
> well.
> 
> 
> >> When things are relatively stable and the ECN-CE marks are being used to
> nudge
> >> the sender's rate based on what the network can absorb, whether ECN-CE
> marks
> >> count as losses or not is probably immaterial - the 10x divergence from the
> TCP
> >> throughput equation's rate is not going to arise, and the circuit breaker won't
> trip.
> >> The circuit breaker is only supposed to trip when things are seriously wrong.
> >
> > Correct.
> >
> >> (1) If the RTP congestion circuit breaker trips based on ECN-CE marks alone,
> >> something feels intuitively wrong - how'd we get to RTP running at 10x the
> >> comparable TCP sending rate with no losses?  Perhaps the circuit breaker
> >> shouldn’t trip on ECN-CE marks alone?
> >
> > Shouldn’t the comparable rate to trigger the circuit breaker be 10x that given to
> a TCP flow subject to the same ECN-CE marking rate? If the TCP treats ECN-CE as
> equivalent to loss, for congestion response, then the circuit breaker should do so
> to, etc.
> 
> First, TCP shouldn’t (treat ECN-CE as equivalent to loss), and so the circuit breaker
> shouldn’t.
> Second, I guess you’re talking about the equation. Well that goes completely
> wrong anyway (the derivation assumes packets to be lost, not marked; then
> again, you’re using loss, not the loss event ratio; then again, you’re close to this
> with ECN perhaps, using “traditional” ECN receiver behavior).
> 
> 
> >> (2) At the other extreme, the congestion circuit breaker clearly has to trip if
> RTP
> >> gets to 10x the comparable TCP sending rate based on losses alone.  This is the
> >> baseline for the circuit breaker to provide network protection as intended.
> >>
> >> So, going back to Gorry's suggestion to use ECN-CE marks as "additional
> evidence,"
> >> here's a straw proposal to shoot at ... factor in ECN-CE marks as additional
> losses
> >> *only when* losses are already occurring.
> 
> I think this is very reasonable.
> 
> 
> >> For example, we could specify that for the RTP congestion circuit breaker to
> trip, the
> >> RTP sending rate has to be:
> >> 	- 10x the equivalent TCP sending rate based on counting ECN-CE marked
> >> 		packets as lost; AND
> >> 	- 3x the equivalent sending rate based on actual drops (i.e., counting
> >> 		ECN-CE marked packets as delivered).
> >> The "3x" above is an off-the-top-of-my-head factor that attempts to roughly
> >> equally weight the inputs (3 is close to the square root of 10) - pick a different
> >> number if that weighting feels wrong.
> >>
> >> This would force drops to occur and then consider ECN-CE marks as additional
> evidence
> >> that something is wrong in the network.
> >>
> >> Another possible rationale for this mixing is that if drops start occurring, then
> many of
> >> the new and proposed uses of ECN that treat ECN-CE marks as less than loss-
> equivalent
> >> are outside their intended operating envelopes/regions.
> >
> > Clearly if the queue has been driven to overflow, so that packet loss is
> occurring, then the AQM is outside its intended operating regime. I’m not sure
> we need to push it so far, though. Is there not a regime where the ECN-CE
> marking rate indicates excessive congestion, before the queue overflows and
> drops packets?
> 
> Shouldn’t a congestion control mechanism react well before that?
> 
> Cheers,
> Michael