Subject: Re: [Mops] Low latency protocol comparision

From: Maxim Sharabayko <[email-masked]>
Date: Tue, 28 Jul 2020 15:06:32 +0000

Hi.

First of all, thank you for the session!
Special thanks to Alexandre for summarizing thoughts and TODOs towards the comparison of protocols.
Sadly we didn't have much time to discuss the comparison initiative.

As a follow up to some questions raised on SRT please see my comments below.

1. SRT versioning and maturity.

SRT is the implementation driven protocol.
We are working on the RFC. It will follow the informational track, and will describe how things are done in the existing implementation.
So it is safe to take the latest library version from GitHub for comparison.

2. Is SRT a transport protocol?

Yes. SRT is a transport protocol agnostic to the payload being transmitted. Any type of content can be sent over SRT: media streams, files, messages, etc.

3. Is SRT fully or partially reliable?

SRT has both modes: fully reliable and partially reliable.

Partially reliable mode is used for live media contribution and distribution. In this mode SRT also manages the end-to-end latency.
Those packets that failed to be recovered within the specified latency window are dropped by SRT to maintain the end-to-end latency constraint.

Fully reliable mode is used in case there is no latency constraints, e.g. file transfer, DASH/HLS segments transfer, message exchange, etc.
In this mode SRT tries to recover every lost packet until it succeeds.

4. SRT goes over TCP?

SRT uses UDP with packet re-transmission (ARQ), FEC, path redundancy (aka bonding coming in v1.5.0).

5. Does SRT overlap with QUIC?

SRT overlaps with QUIC only in fully-reliable transmission mode.
Both protocols are built on top of UDP and provide fully reliable delivery.

QUIC datagram does not overlap with the partially reliable mode of SRT.
Unlike QUIC datagram, SRT tries to recover lost packets within the latency constraints.
All packet recovery techniques can still be used in this mode.

6. Where does SRT stand?

The main use case for SRT is 6.1.

6.1. Low-latency contribution and distribution. Protocols to compare with: RTMP, RTP, RTSP.
There is a comparison of SRT vs RTMP performed by Haivision.
Potentially some thoughts and workflows could be taken from there to start with.
https://www.haivision.com/resources/white-paper/srt-versus-rtmp/

6.2. Fully-reliable transport. Protocols to compare with: QUIC, TCP.

The initial goal was to compare low latency protocols. So probably to reduce the scope it is better to start with 6.1 .

Kind regards,

Maxim Sharabayko

From: Kyle Rose<mailto:[email-masked]>
Sent: Thursday, June 25, 2020 00:37
To: Leslie Daigle<mailto:[email-masked]>
Cc: Alexandre GOUAILLARD<mailto:[email-masked]>; Deen, Glenn<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Maxim Sharabayko<mailto:[email-masked]>
Subject: Re: [Mops] Low latency protocol comparision

On Wed, Jun 24, 2020 at 6:16 PM Leslie Daigle <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Speaking as only one of the chairs of this group, I have to say I like how this is shaping up.

My only question is whether there is work to be done even at the IETF 108 hackathon, in order to establish the test cases and test suite?

Happy to hear from the other co-chair of this group :^) and any other group participants.

Heh...  As the other co-chair, Leslie and I are in alignment on this. If there's prep work to be done at the 108 hackathon, great! If not, BKK (or, likely, the virtual replacement for it) sounds like a plan. Even if we don't do anything at the 108 hackathon, there's probably a bit of prep we'll want to do prior to the 109 hackathon, including coordinating with Charles on any special network setup we might need should the meeting be held in person.

Kyle

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 29 Jul 2020 07:02:14 +1200

According to this Wikipedia page
	https://en.wikipedia.org/wiki/Reliable_Internet_Stream_Transport
there’s another protocol - “RIST” - that’s "intended as a more reliable successor to Secure Reliable Transport, and as an open alternative to proprietary commercial options…”

If that’s the case, shouldn’t the IETF be focused on documenting/standardizing *this* protocol, rather than SRT?

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: "Leslie Daigle" <[email-masked]>
Date: Tue, 28 Jul 2020 15:57:00 -0400

The focus of discussion stems from a comparison of low-latency 
protocols; since that comparison was deemed inadequate, the question is 
whether we can set up a better comparison framework and testing at a 
hackathon.

At which point I’d say we could/should test any interested protocol.

At no point is this discussion (or this WG) about which protocols should 
be standardized by the IETF.

Leslie.

On 28 Jul 2020, at 15:02, Ross Finlayson wrote:

> there’s another protocol - “RIST” - that’s "intended as a more 
> reliable successor to Secure Reliable Transport, and as an open 
> alternative to proprietary commercial options…”
>
> If that’s the case, shouldn’t the IETF be focused on 
> documenting/standardizing *this* protocol, rather than SRT?
> 	
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
> -- 
> Mops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mops

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: Glenn Deen <[email-masked]>
Date: Tue, 28 Jul 2020 13:28:46 -0700

Hi Ross,

That’s a good question.  

SRT is in wide use today as a production protocol, and is also open source (to be clear as a top quick read of the wiki article may lead someone to think that it isn’t.)   and it has marketplace adopters that are interested in seeing it evolve, and hopefully some of them would contribute or support any work we did.

Despite the statement in the Wikipedia article that RIST is intended as a replacement for SRT that doesn’t necessarily mean that the marketplace is agreeing to drop SRT. 

 I don’t mean to be nasty to RIST, perhaps the market may go that way someday,  but I see a widely adopted protocol in SRT and a set of features that it could use as improvements and work that’s relevant the transport and media operations work at the ietf.

Glenn 

> On Jul 28, 2020, at 12:03 PM, Ross Finlayson <[email-masked]> wrote:
> 
>    https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Reliable_Internet_Stream_Transport__;!!PIZeeW5wscynRQ!4OdDk9MtuOz667GINmkargAg3Ak-6qYTcjjqijoznxzVxOKk_IcTuUCljNTpxnjo$ 
> https://urldefense.com/v3/__http://www.live555.com/__;!!PIZeeW5wscynRQ!4OdDk9MtuOz667GINmkargAg3Ak-6qYTcjjqijoznxzVxOKk_IcTuUCljDLUkQCR$ 
> 
> -- 
> Mops mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mops__;!!PIZeeW5wscynRQ!4OdDk9MtuOz667GINmkargAg3Ak-6qYTcjjqijoznxzVxOKk_IcTuUCljHaW6KP4$

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 29 Jul 2020 05:03:53 -0500

Hi, Maxim,

On Tue, Jul 28, 2020 at 10:06 AM Maxim Sharabayko <
[email-masked]> wrote:

> We are working on the RFC. It will follow the informational track, and
> will describe how things are done in the existing implementation.
>

Could you confirm that this draft is ready for clarifying issues and pull
requests from the rest of us?

I'd definitely like to see it move forward toward publication (since as
Ross said, it IS widely deployed).

Best,

Spencer

---

From: Maxim Sharabayko <[email-masked]>
Date: Wed, 29 Jul 2020 11:01:30 +0000

Hi Spencer,

> Could you confirm that this draft is ready for clarifying issues and pull requests from the rest of us?
> I'd definitely like to see it move forward toward publication (since as Ross said, it IS widely deployed).

Issues and pull requests are always welcome!
We are working on the encryption and congestion control sections.
The rest of the RFC will likely go as it is now to the editorial review.

--
Regards,
Maxim Sharabayko