Subject: Re: [rmcat] SCReAM status and way forward

From: "Ralf Globisch" <[email-masked]>
Date: Wed, 01 Jun 2016 15:11:03 +0200

Hi Ingemar,

> And thanks for the effort, worth a lot. 

Great, I was just interested in seeing how the proposed rmcat congestion control mechanisms work in the 'real' world.
When running RTP sessions between my home ADSL line and my work, I would get results every now and againwhere the rate would increase nicely up to a couple of 100kbps, but most of the time, it would try to increase
and then just stay at 50 kbps. It could however just have been the state of the network, ADSL, time of day, etc.

> I assume that you have used the C++ code
(https://github.com/EricssonResearch/scream) in your implementation?

Yes, correct, though I made some minor modifications to be able to compile it on linux without the glib dependency.

> 50kbps is a very low bitrate for video, there are a few things that can
> cause extra trouble. 

> + RTCP overhead. At bitrates this low it is sufficient with feedback
> intervals around 200ms, furthermore reduced size RTCP (RFC5506) is highly> recommended, this will give you an RTCP overhead of ~3-5kbps, so a
> recommendation is that you have a look at how much bandwidth RTCP consumes.
> Is reduced size RTCP implemented in your RTP library ?, it is implemented in
> the GStreamer libraries if you wish to have a look at how it is done.

Yes, I have implemented reduced size RTCP. I do have some code to measure RTCP rates.Let me come back to you on this one.

> + RTP overhead. The function getTargetBitrate has a comment in the header file
> This means that, if the size argument in the addTransmitted function
> includes also the size of the RTP header (+ possible extensions) then the
> computed bitrate is the bitrate with the RTP overhead included. This means
> that you need to subtract the bitrate given by the RTP overhead when you
> compute the video coder bitrate. The function to compute the video coder
> bitrate is thus.
> videoBitrate = getTargetBitrate(..)+rtpOverheadBitrate.
> A somewhat better alternative, used in the OpenWebRTC implementation is to
> use the RTP payload size as input to the addTransmitted(..) function.

Ok, I didn't take only payload size into account. Will look at this too.
 
> + Video coder output. My grim experience is that the video coder does not
> always output the desired target bitrate, variations around the target
> bitrate is natural but in some cases I have seen that the output bitrate is
> consistently 10-20% above the target bitrate, for that reason it could be
> good to compute and log the video coder output bitrate. In some cases the
> video coders are in a non-rate adaptive mode or have the internal rate
> control tuned too slow, this is a tuning matter. I have fiddled a bit with
> OpenH264 and VP8, which video codec do you use ?

I can't remember offhand what I was using at the time. I had written some CBR video traffic 
generators, and played around with various H.264 codec implementations, x264, OpenH264, 
and our own H.264 codec that can be configured to output exact bytes/frame which is useful 
for low bitrate video configurations.

> I have only tried out these low bitrates with the experimental code, the
> code is adapted for audio streaming so it should not be any problems to
> congestion control video  over 50kbps bottlenecks. 

Ok.

> With the OpenWebRTC implementation I managed to push down the bottleneck
> bitrate down to 200kbps. The problem there is that I did not have full
> control over the RTP stack and that RTCP tended to consume too much
> bandwidth.

Ok. Are you're using RFC4585? And what is the frequency of RTCP reports?

> That said, there are probably some yet to discover issues, it is not too
> unlikely that you have found an issue in  SCReAM but one probably need to
> rule out the  possible issues above before. 

For sure, I've been meaning to get back to my experiments. You've motivated me
to get the experiments back up and running and look into it further.
 
> Is your fork available somewhere ?, could be interesting to try it out as
you have integrated it into an RTP library.

The fork only has minor modifications:
- added CMake build files though I've only tested the build on linux. Some modifications might be necessary for windows compilation.
- replaced glib-specific types with std c++ types. 
It's available at https://github.com/miseri/scream
 
I think more interesting would be the code where I've wrapped up the SCReAM classes for use in the RTP library.It could well be that I'm using the SCReAM classes incorrectly or in an unintended way.
I could share this with you off-list if you're interested?

Regards
Ralf

 

"Ralf Globisch" <[email-masked]> Tue, 31 May 2016 19:14 UTC
<https://mailarchive.ietf.org/arch/search/?email_list=rmcat> Show header

Ingemar, for what it's worth, I forked the SCReAM code on github and
integrated it into an RTP library.
I ran some preliminary tests streaming video over my home ADSL line, but
often found that the algorithm
struggled to stream at higher rates than the minimum (in my case I used
50kbps as the minimum). 
If I understand correctly, the algorithm is designed for use over mobile
networks and not ADSL though. 
If you're interested, perhaps we could investigate the behaviour of the
algorithm on other network types, etc.
It could be that some fine-tuning, etc is needed to make it work in such
cases. Of course it could also be,
that I was not using your code as intended...

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

---

From: "Ralf Globisch" <[email-masked]>
Date: Fri, 03 Jun 2016 10:49:20 +0200

Hi Ingemar,

Responses inline.

> [IJ] Great, that can play a role, SCReAM can compensate for minor errors but
> if they become too bit and systematic then the rate/congestion control becomes
> confused.

Ok, cool, will keep this in mind when running my next round of tests.

> [IJ] The OpenWebRTC implementation seemed to set the RTCP BW
> proportional to the RTP media rate, I suspect that it was those 5%. The
> problem is that this was way too low in the beginning and caused choppy video
> in the beginning, after a while the feedback interval became unnecessary. As I
> understood things RFC4585 is implemented but not 100% sure. The best is to
> steer the RTCP feedback according to the outlined function on page 14 in
> http://www.ietf.org/proceedings/95/slides/slides-95-rmcat-1.pdf . trr-int
> should be a set to sufficiently high value to avoid that full compound RTCP is
> transmitted too often, 500ms should be sufficient in your case.

Ok.

 > [IJ] Sure, I'll be interested to do a testrun if I manage to build it.

 Ok, I'll see if I can put a release together for testing. I'm just a bit swamped with 
work at the moment, so it might take me a while to get to it.

On the way forward, I will take your feedback into account, and get in touch if I have any questions
regarding the behaviour/tweaking of SCReAM. We're intending to look at how it performs especially 
over EDGE/3G/H+ which are prevalent in developing contexts.

Regards,
Ralf

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 8 Jun 2016 13:43:23 +0000

Hi Ralf

Thanks, It will be interesting to see what results you get with EDGE/3G/H+. 
Unfortunately I don't have any real test results with wireless access available. I have done simulations with LTE and HSDPA+EUL. LTE should work fine and HSPA should be doable too.
It can be a challenge to get video working over EDGE but it may work. Please let me know your findings.

Regards
/Ingemar

> -----Original Message-----
> From: Ralf Globisch [mailto:[email-masked]]
> Sent: den 3 juni 2016 10:49
> To: Ingemar Johansson S <[email-masked]>;
> [email-masked]
> Subject: Re: RE: RE: [rmcat] SCReAM status and way forward
> 
> Hi Ingemar,
> 
> Responses inline.
> 
> > [IJ] Great, that can play a role, SCReAM can compensate for minor
> > errors but if they become too bit and systematic then the
> > rate/congestion control becomes confused.
> 
> > proportional to the RTP media rate, I suspect that it was those 5%.
> > The problem is that this was way too low in the beginning and caused
> > choppy video in the beginning, after a while the feedback interval
> > became unnecessary. As I understood things RFC4585 is implemented but
> > not 100% sure. The best is to steer the RTCP feedback according to the
> > outlined function on page 14 in
> > http://www.ietf.org/proceedings/95/slides/slides-95-rmcat-1.pdf .
> > trr-int should be a set to sufficiently high value to avoid that full compound
> RTCP is transmitted too often, 500ms should be sufficient in your case.
> 
> Ok.
> 
>  Ok, I'll see if I can put a release together for testing. I'm just a bit swamped
> with work at the moment, so it might take me a while to get to it.
> 
> On the way forward, I will take your feedback into account, and get in touch
> if I have any questions regarding the behaviour/tweaking of SCReAM. We're
> intending to look at how it performs especially over EDGE/3G/H+ which are
> prevalent in developing contexts.
> 
> Regards,
> Ralf
> 
> 
> 
> --
> This message is subject to the CSIR's copyright terms and conditions, e-mail
> legal notice, and implemented Open Document Format (ODF) standard.
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 13 Jun 2016 06:18:34 +0000

Hi Ralf

One (two) additional item(s) that I forgot to mention. 

1) 
There is in SCReAM a feature that tries to sense the presence of competing traffic (for instance TCP based file transfers), this feature decreases the sensitivity to congestion. Even though it does its job reasonably well and makes it possible to get some decent SCReAM throughput even in the presence of TCP in tail drop links, I don't like it at all as it is a potential footgun and can easly cause self-inflicted congestion (large RTTs) in the more tricky wireless scenarios like the ones you are looking at.  

So, .. assuming that you have very limited throughput in your test scenarios and that you probably want to avoid large file transfers that compete with the realtime video anyway, it is recommended that you change the line below in ScreamTx.cpp
static const gboolean kEnableSbd = TRUE;
to 
static const gboolean kEnableSbd = FALSE;

2)
And.. If you get started with your experiments and face problems with stability (not too unlikely), it can be good to use the printLog() in ScreamTx.cpp, if you email me the log then I can do some initial debugging based on this information, just prepend each line in the log with a timestamp to make it easier to follow.

/Ingemar

> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: den 8 juni 2016 15:43
> To: [email-masked]; [email-masked]
> Cc: Ingemar Johansson S <[email-masked]>
> Subject: Re: [rmcat] SCReAM status and way forward
> 
> Hi Ralf
> 
> Unfortunately I don't have any real test results with wireless access available.
> I have done simulations with LTE and HSDPA+EUL. LTE should work fine and
> HSPA should be doable too.
> > > became unnecessary. As I understood things RFC4585 is implemented
> > > but not 100% sure. The best is to steer the RTCP feedback according
> > > to the outlined function on page 14 in
> >  Ok, I'll see if I can put a release together for testing. I'm just a
> > bit swamped with work at the moment, so it might take me a while to get
> to it.
> >
> > On the way forward, I will take your feedback into account, and get in
> > touch if I have any questions regarding the behaviour/tweaking of
> > SCReAM. We're intending to look at how it performs especially over
> > EDGE/3G/H+ which are prevalent in developing contexts.
> >
> > Regards,
> > Ralf
> >
> >
> >
> > --
> > This message is subject to the CSIR's copyright terms and conditions,
> > e-mail legal notice, and implemented Open Document Format (ODF)
> standard.