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

["Fred Baker (fred)" <[e-mail]>]

On Jun 14, 2016, at 6:59 AM, John Leslie <[e-mail]> wrote:
>   We must find a way to avoid ECN-CE triggering the congestion circuit
> breaker when the forwarding node has not reached a level of congestion
> which could trigger packet loss.

I'm not sure I agree.

I tend to think that ECN is relatively cheap - it asks the sender to reduce its effective window but doesn't make him retransmit anything and causes no delivery delay - while packet loss is relatively expensive in that it makes the sender retransmit and introduces at least a one RTT hiccup ( to detect and retransmit the lost packet) in the transmission stream. Neither actually changes the rate at which anyone sends (we talk about the signal asking the sender to slow down, but the rate demonstrably doesn't actually change - we're asking the sender to not pack the pipe so full).

When ECN does ask someone to reduce their effective window, if they are typically increasing it by one per RTT, ECN could very logically reduce it by a small amount, such as two or three. If it reduced it by two, for example, that would cause it to skip the next two transmission opportunities (the next two received acknowledgements, which might actually arrive in the same ack), and would be back to the same level two RTTs later. If ECN is typically keeping the delay relatively shallow, it is oscillating between "a little shallower" and " a little less shallow". So it gets CE every other RTT? So what? If I'm dropping a packet, or a couple of packets, every other RTT, we're going to see notes on NANOG and other lists. "Your network's broken again. It's dropping packets."

I could be argued into setting the CE threshold a little lower than the discard threshold. There are probably some mechanisms we'd do well to explore, but...