Ultra Low-Latency Capabilities

[kenyonja]

Regarding the statements in clause 3.1 about a lack of success in Ultra Low-Latency streaming, and that replicating streams is "nearly impossible to achieve", there are implementers that are able to stream content to audiences numbering in the hundreds of thousands with a latency of less than half a second.

Suggest revisiting this area of the text to note that, while delivering ultra low-latency content to large audiences can be challenging, it is indeed possible.

[gitnnelg]

On 8/24/21, 10:25 AM, "kenyonja" @.**@.>> wrote:

Regarding the statements in clause 3.1 about a lack of success in Ultra Low-Latency streaming, and that replicating streams is "nearly impossible to achieve", there are implementers that are able to stream content to audiences numbering in the hundreds of thousands with a latency of less than half a second.

Suggest revisiting this area of the text to note that, while delivering ultra low-latency content to large audiences can be challenging, it is indeed possible.

Do you have examples of services that are doing sub 0.5s at the scale of hundreds od thousands? What I’ve understood from services going ULL streaming is that they focus on a sub-set core of participants which get the ULL delivery, with the remainder of participants getting a slightly high latency delivery. So they are effectively are providing a range of latencies to different groups all watching the same event.

If there are services that have figured out how to do everyone at ULL that would be good citations to consider including.

-glenn

[englishm-ietf]

I'm still looking for public materials with concrete numbers I that could be cited, but anecdotally, I will say that Limelight's WebRTC-based "Realtime Streaming" platform is capable of delivering sub 0.5s latency streams to globally dispersed audiences on the same order of magnitude @kenyonja mentioned.

[englishm-ietf]

OK, this page at least says:

Scalability 10s – 100Ks delivered upon request globally.

https://www.limelight.com/resources/data-sheet/realtime-streaming/

[kenyonja]

One example is Phenix; we've streamed to over 450,000 concurrent users. https://www.statsperform.com/press/racecourse-media-group-sees-record-streaming-volumes-at-cheltenham-festival-using-phenix-real-time-streaming/ https://advanced-television.com/2018/09/12/phenix-sub-0-5s-latency-video-with-ex-machina-group/

[acbegen]

OK here is our proposal for the 2nd parag. in Section 3.1:

Some media content providers aim to achieve this level of latency for live media events involving sports. This introduces new challenges relative to less-restricted levels of latency requirements because this latency is the same scale as commonly observed end-to-end network latency variation (for example, due to effects such as bufferbloat, Wi-Fi error correction, or packet reordering). These effects can make it difficult to achieve this level of latency for the general case, and may require tradeoffs in relatively frequent user-visible media artifacts. However, for controlled environments or targeted networks that provide mitigations against such effects, this level of latency is potentially achievable with the right provisioning.

[acbegen]

We also suggest to replace the 5th parag. as follows:

Worth noting is that many applications for ultra low-latency delivery do not need to scale to more than a few users at a time, which simplifies many delivery considerations relative to other use cases.

[englishm-llnw]

Thank you, @acbegen!

I will say that "sports" is only one of several use cases we've seen, so I don't know if we need to make that description application specific in the proposed 2nd parag. in Section 3.1 text. The rest of the proposed text seems reasonable to me.

[acbegen]

Yeah, we can remove sports from that sentence.

[SpencerDawkins]

Should be resolved with commits/prs.