Subject: [rmcat] Datachannel support

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 8 Feb 2019 15:58:09 +0100

Hi all,

Sorry if this question has been already raised in the list already, I 
had to admit that I don't follow it as much as I should.

I was wondering if the support of  WebRTC Datachannels have been 
considered in any in the rmcat algorithms/drafts. I am implementing a 
datachannel lib with my own ad-hoc stack and I wanted to try to use the 
share the congestion control & bandwidth estimation with RTP and 
Datachannels instead of implementing the SCTP one.

In theory it is covered in the requirements document, but I have not 
found any other reference within the group documents.

Best regards

Sergio

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 11 Feb 2019 08:11:08 +0000

Hi

Not sure if it has been discussed in RMCAT but I know for sure that there has 
been ideas around this.

My personal feeling  is that a few years back it could have been a good to add 
data channel support as well. Today I am less convinced, I believe that it is 
likely a better idea to place the effort and energy on QUIC instead. There are 
some initiatives there to add support for media streams, add an appropriate 
congestion control there (BBR, Prague, PCC.. ) and you'll have support for 
both media and data in one package.

Regards
Ingemar

-----Original Message-----
From: Sergio Garcia Murillo <[email-masked]>
Sent: den 8 februari 2019 15:58
To: [email-masked]
Subject: [rmcat] Datachannel support

Hi all,

Sorry if this question has been already raised in the list already, I had to 
admit that I don't follow it as much as I should.

I was wondering if the support of  WebRTC Datachannels have been considered in 
any in the rmcat algorithms/drafts. I am implementing a datachannel lib with 
my own ad-hoc stack and I wanted to try to use the share the congestion 
control & bandwidth estimation with RTP and Datachannels instead of 
implementing the SCTP one.

In theory it is covered in the requirements document, but I have not found any 
other reference within the group documents.

Best regards

Sergio

---

From: "Flohr, Julius" <[email-masked]>
Date: Mon, 11 Feb 2019 08:52:03 +0000

Hi

I have done some work in the field of congestion control interaction in the context of RMCAT and Datachannel streams. 
The basic idea behind it is that I use congestion control information from the rmcat stream to compute how much data may be sent safely by SCTP without inducing extra queueing delay or packet loss.
If you're interested, you can find a copy of the work here: https://owncloud.tdr.uni-due.de/index.php/s/Uy2mdrM4Z8C1IdU
This also includes a modified version of Safiqul's Flow State Exchange which allows enforcement of different bandwidth priorities. 
So far everything has been done in a discrete event simulation environment, but I would be more than thrilled to see some real world results. Feel free to contact me anytime if you have questions.

Also, I'm currently looking at the impact of BBR on NADA streams (spoiler: Not good). If there is a general interest in this topic, I'd be willing to give a short presentation about this in Prague (or Montreal if the slot is full). 

Regards

Julius

> On 11. Feb 2019, at 09:11, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi
> 

=====================================
Julius Flohr, M.Sc.
University of Duisburg-Essen
Computer Networking Technology Group

Room SL-408
Schützenbahn 70
D-45326 Essen/Germany

E-Mail:  [email-masked]
Phone: +49-201-183-7667
Fax:     +49-201-183-7673
=====================================

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 11 Feb 2019 10:09:57 +0100

Hi Ingemar,

While I am special interested in the work being done around QUIC, if we 
follow that reasoning, we should also stop any work being done in this 
group as RTP will be also replaced by QUIC.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 11 Feb 2019 10:22:37 +0100

Hi Julius,

This looks really interesting. My stack is still on early stages, but 
will definitively see if I can apply it when it is more mature.

I was also considering if it could be viable to extend the feedback 
mechanism to include DTLS sequence numbers of datachannel data and use 
that information to calculate the estimation of the total ICE transport.

Best regards
Sergio

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 11 Feb 2019 14:28:59 +0000

Hi

I would believe that RTP will be around for a long while to come so I guess 
that would justify whatever activities that are within the current charter of 
the RMCAT.
Of course if there is interesting work in the form of interfacing any given 
RMCAT congestion control with SCTP, then I have nothing against it if people 
want to devote time to it.

/Ingemar

-----Original Message-----
From: Sergio Garcia Murillo <[email-masked]>
Sent: den 11 februari 2019 10:10
To: Ingemar Johansson S <[email-masked]>; [email-masked]
Subject: Re: [rmcat] Datachannel support

Hi Ingemar,

While I am special interested in the work being done around QUIC, if we follow 
that reasoning, we should also stop any work being done in this group as RTP 
will be also replaced by QUIC.

Best regards
Sergio

On 11/02/2019 9:11, Ingemar Johansson S wrote:
> Hi
>
> Not sure if it has been discussed in RMCAT but I know for sure that
> there has been ideas around this.
>
> My personal feeling  is that a few years back it could have been a
> good to add data channel support as well. Today I am less convinced, I
> believe that it is likely a better idea to place the effort and energy
> on QUIC instead. There are some initiatives there to add support for
> media streams, add an appropriate congestion control there (BBR,
> Prague, PCC.. ) and you'll have support for both media and data in one 
> package.
>
> Regards
> Ingemar
>
> datachannel lib with my own ad-hoc stack and I wanted to try to use
> the share the congestion control & bandwidth estimation with RTP and

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 11 Feb 2019 17:18:21 +0100

Hi Ingemar,

I hope it is still around for time and we are not forced to use QUIC to 
be able to achieve same performance when using media+datachannels, so 
excuse me if my previous response sounded blunt, which was not my intention.

Trying to be constructive, not sure if we would need to interface with 
the SCTP layer, or we could just work on the DTLS layer in which the 
SCTP layers are encapsulated.

 From my point of view behavior of the RTP packets and DTLS/SCTP packets 
are quite similar network wise, so I am wondering if we could just 
consider the DTLS data flow just as an "independent" rtp stream and 
apply current algorithms to it. For example, in SCReAM the only missing 
piece would be to define how the Media Rate Control interacts with the 
SCTP stack to define the rate of packets that are put on the SCTP packet 
queue, that will be later processed by the Sender Transmission Control 
as any other RTP paquet queue.

That would require to feedback either DTLS packets same way that we do 
RTP packets (but luckily DTLS already have a seq number we can reuse) or 
reuse SCTP sack info (but it will lack timing information, and it won't 
work if there is no media sent together with DC).

Most probably I am just being naive, but would love to hear what other 
people think about this and in which parts I am wrong.

Best regards
Sergio