Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Magnus,

I have to add one more point here. See below.

> Am 18.05.2016 um 14:55 schrieb Magnus Westerlund <[e-mail]>:
> 
> Hi Mirja,
> 
> I will let the authors and anyone else who want to provide input do so now. From my perspective we clarified the positions and possibilities a bit more by this exchange.
> 
> Den 2016-05-18 kl. 14:17, skrev Mirja Kuehlewind (IETF):
> 
>> My personal opinion is that I would not consider ECN at all. However
>> my Discuss this that the doc simply should not say
>> 
>> "ECN-CE marked packets SHOULD be treated as if they were lost when
>> calculating if the congestion- based RTP circuit breaker“
>> 
>> There is currently no document that says that both signal have to be
>> treated differently but there is also no document that defines that
>> they have to be the same for circuit breakers. This doc would be the
>> first one doing so. Given the currently knowledge we have and the
>> current work we are doing, this is simply wrong.
> 
> One question that will arise if one remove ECN-CE marks as input, that is if the RTP-CB is at all applicable to be used in RTP sessions where one have negotiated ECN Capable Transport (ECT). I guess you would say yes, based on the arguments so far has brought up. From my perspective, I would have to say questionable, as this could result in that the RTP flow would have the possibility in some cases to cause persistent congestion, without ever having the possibility to trigger for this.
> 
> So a possibility could be to remove ECN-CE reaction and at the same time reduce the applicability of the specification. Then address this in the future when we know what the updated ECN-CE semantics is.

Removing ECN, would basically mean you cannot use ECN with most RTP application because you really should implement a CB. That would be not a great solution from point of view.

However, there good arguments for e.g. using a higher threshold for ECN. As a side note I have to say that the value for loss (k=10) is also rather random, there the value itself for ECN can only be random as well (but should be higher).

Then first of all, all networks try to minimize loss as loss is basically lost transmission capacity. There is no such an incentive to minimize ECN marks. The usually assumption we can make today is that most loss-based queues are droptail, while whenever you decide to enable ECN you have to use an AQM scheme with a lower threshold then the maximum queue size. In this situation you will see more marking than you have seen losses with droptail.

Then even if you use the same AQM for loss and ECN, you usually see more ECN markings than losses, because we a packet is dropped the queue shrinks, while a marking keeps the queue growing and causes more markings. This is less a problem for congestion control, as it only reacts once per RTT. However this doc says that the actual rate of losses or ECN marks should be considered.

So just given the way ECN works, it’s simply different from loss. This difference is not that important for congestion control. But the way it is used in this doc, it is.

Finally, I really would like to avoid a situation, where, as ECN is basically not enable in the network right now, an operator decides to enable ECN and suddenly all WebRTC connections crash. This would be a strong disincentive to deploy ECN while we are working very hard on finally deploying it, especially as services like WebRTC could really benefit from it.

Mirja

> 
>> 
>> However, I did not say that you cannot use ECN-CE as an input for a
>> circuit breaker at all (if you really want to), just treat it not the
>> same but different.
> 
> And I don't see how we can arrive at such an answer prior to updated semantics for the ECN-CE has been defined. Then you can determine what is reasonable response for a CB. From my perspective we can't have this circuit breaker wait for such work.
> 
>> 
>>> From my personal point of view there are two options here:
>> 
>> 1) have a separate counter for ECN-CE with a much higher threshold
>> than for loss, or
>> 
>> 2) make sure that there are not only ECN-CE markings but also loss
>> (maybe with a certain minimum rate).
> 
> The issue is to set the parameters for these in a correct (or even mostly working) way. We have no way of knowing if these would work well with the future semantics.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>