Subject: [tsvwg] Codecs, circuit breakers and TDM PWs

From: "Black, David" <[email-masked]>
Date: Mon, 3 Jan 2022 22:17:12 +0000

<WG Chair Hat OFF>

The following discussion between Stuart and Bob ranged over an interesting set of topics related to voice traffic, including mention of RFC 7893.

As one of the authors of RFC 7893, I thought I ought to write a response.  Here's the discussion, my comments follow:

> > Stuart

> Bob

> > Page 20, 'Safe' Unresponsive Traffic

> >     The above section requires unresponsive traffic to be 'safe' to mix

> >     with L4S traffic.  Ideally this means that the sender never sends any

> >     sequence of packets at a rate that exceeds the available capacity of

> >     the bottleneck link.  However, typically an unresponsive transport

> >     does not even know the bottleneck capacity of the path, let alone its

> >     available capacity.  Nonetheless, an application can be considered

> >     safe enough if it paces packets out (not necessarily completely

> >     regularly) such that its maximum instantaneous rate from packet to

> >     packet stays well below a typical broadband access rate.

> >     This is a vague but useful definition, because many low latency

> >     applications of interest, such as DNS, voice, game sync packets, RPC,

> >     ACKs, keep-alives, could match this description.

> > This makes me very nervous.

> > I agree that it is vague, but I don't think it's useful.

> > A bunch of people doing voice calls over a shared slow Internet connection

> > (think beach café on some remote island) could easily overwhelm the available

> > capacity, and their clients should react by selecting a lower-rate voice codec,

> > not by driving the network into massive packet loss so that nothing works.

> > Conversely, if spare capacity is available, the clients should react by selecting

> > a higher-rate voice codec to make use of that extra capacity and give better

> > voice quality. I don't see any good reason why voice clients, or video games,

> > should not adapt to give the best user experience possible on a given network

> > capacity. And that adaptation includes adapting down as well as adapting up.

> > A voice call that adapts down (and works) gives a better user experience than

> > a voice call that drives the network into congestion collapse (and completely fails).

> [BB] Totally agree. This was meant to be explained by the mention of

> available capacity in "...does not even know the bottleneck capacity of

> the path, let alone its available capacity."

> I've attempted to remedy this by adding the following at the end of the

> subsection about "'Safe' Unresponsive Traffic":

> "Low rate streams such as voice and game sync packets, might not use

> continuously adapting ECN-based congestion control, but they ought to at

> least use a 'circuit-breaker' style of congestion response [RFC8083].

> Then, if the volume of traffic from unresponsive applications is high

> enough to overload the link, this will at least protect the capacity

> available to responsive applications. However, queuing delay in the L

> queue will probably rise to that controlled by the Classic (drop-based)

> AQM. If a network operator considers that such self-restraint is not

> enough, it might want to police the L queue (see Section 8.2 of

> [I-D.ietf-tsvwg-l4s-arch]."

> You didn't give an indication of what you wanted me to do. Does this help?

> BTW, I resisted the temptation to also cite RFC7893, which favourably

> compares the ITU-recommended termination of voice calls due to high loss

> with TCP's congestion response, and goes on to calculate how large a

> pseudowire of multiple voice circuits can be before it is worse than

> TCP's response.

Stuart's primary concern appears to be that the "maximum instantaneous rate from packet to packet stays well below a typical broadband access rate" heuristic implicitly assumes broadband access, and hence may be problematic when that's not present, e.g., "shared slow Internet connection (think beach café on some remote island)".  In other words, if one does not know the available access rate, one does not know what a low-rate stream is, with voice being a fine example of the problem - a voice flow has to cause network congestion in order to see the feedback that causes it to shift to a lower rate codec.  The NQB draft is slightly better on this point as it recommends a 1 Mb/sec rate cap on non-responsive traffic (see Section 4.1).

IMHO, it'd be better to cover this topic (characterization of NQB/"safe" traffic that is ok to mix with low-latency L4S traffic) once, and the NQB draft strikes me (as an individual) as a more appropriate place than the L4S architecture draft.  I'd hope this could be done without making the NQB draft a normative reference.

Beyond this, somehow, I don't see how a codec down-shift to a lower transmission rate can be characterized as a 'circuit-breaker' - I expect a circuit breaker to break the circuit.  In contrast ...

Not citing RFC 7893 was a good move (IMHO) because that RFC has very limited applicability - it is only about classic POTS TDM pseudowires (PWs), e.g., for T1 or T3 service.  These PWs are fixed-rate (e.g., Stuart's rate-adaptive codec discussion does not apply), and have limited error recovery capabilities, so drops tend to manifest as voice errors.  Under those restrictive assumptions, RFC 7893 in effect explains that the ITU criteria for acceptable (voice) service can be used to define a circuit breaker for these specific PWs - i.e., as network drop rate rises, service (voice) quality becomes unacceptable before a TFRC calculation would indicate that the PW sending rate is high enough to be unfriendly to TCP traffic.  That's not a generally applicable result beyond these PWs, and should not be treated as such (reminder: I'm an author of RFC 7893).

</WG Chair Hat OFF>

Thanks, --David

---

From: Kyle Rose <[email-masked]>
Date: Tue, 4 Jan 2022 10:04:56 -0500

On Mon, Jan 3, 2022 at 5:17 PM Black, David <[email-masked]> wrote:

> Beyond this, somehow, I don't see how a codec down-shift to a lower
> transmission rate can be characterized as a 'circuit-breaker' – I expect a
> circuit breaker to break the circuit.  In contrast …
>

To this limited point, do we need a more precise taxonomy for
responsiveness? There seem to be two dimensions of congestion
responsiveness: latency and granularity. TCP does well on both: it will
respond in just over 1 RTT, and it can get arbitrarily slow. Rate-adaptive
video is also responsive, but more slowly (players don't downgrade
immediately, but switch after some loss threshold is crossed) and with a
non-zero minimum (maybe the lowest available bitrate is 500 Kb/s). But the
latter is usually described as non-responsive, presumably because it relies
on the application layer to respond, rather than the transport layer, with
transport-layer CC backing off much more quickly.

(Multicast, by contrast, is properly classified as non-responsive because
the receiver has only binary control over individual flows: the hose is
either open or closed. So congestion control is limited to circuit breaking
on individual flows.)

It seems like we need a more fine-grained taxonomy for responsiveness, and
in designing for low-latency transports admit the existence of congestion
controls at higher layers that we should leverage rather than ignore.

Kyle

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 13 Jan 2022 14:22:28 +0000

Hi

Not sure how relevant it is in this context. 

For 3GPP systems, also rate-adaptive video needs to respond in pretty much the same way as TCP to avoid excessive queue build up or packet loss. 

The plain reason is that the 3GPP systems allocate system resources between users in a reasonably fair fashion (such as round-robin scheduling). 

Therefore, it is not very helpful for rate-adaptive video to be slow  with the rate decrease as the end result will only be (very) high latency.

RFC8298 is designed based on this constraint.

Regards
Ingemar

From: tsvwg <[email-masked]> On Behalf Of Kyle Rose
Sent: den 4 januari 2022 16:05
To: Black, David <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] Codecs, circuit breakers and TDM PWs

On Mon, Jan 3, 2022 at 5:17 PM Black, David <[email-masked] <mailto:[email-masked]> > wrote:

Beyond this, somehow, I don't see how a codec down-shift to a lower transmission rate can be characterized as a 'circuit-breaker' – I expect a circuit breaker to break the circuit.  In contrast …

To this limited point, do we need a more precise taxonomy for responsiveness? There seem to be two dimensions of congestion responsiveness: latency and granularity. TCP does well on both: it will respond in just over 1 RTT, and it can get arbitrarily slow. Rate-adaptive video is also responsive, but more slowly (players don't downgrade immediately, but switch after some loss threshold is crossed) and with a non-zero minimum (maybe the lowest available bitrate is 500 Kb/s). But the latter is usually described as non-responsive, presumably because it relies on the application layer to respond, rather than the transport layer, with transport-layer CC backing off much more quickly.

(Multicast, by contrast, is properly classified as non-responsive because the receiver has only binary control over individual flows: the hose is either open or closed. So congestion control is limited to circuit breaking on individual flows.)

It seems like we need a more fine-grained taxonomy for responsiveness, and in designing for low-latency transports admit the existence of congestion controls at higher layers that we should leverage rather than ignore.

Kyle