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

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

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?

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.

(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?

(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.   

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.

Thanks, --David