Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 4 Aug 2014 16:17:26 +0000

Hi Piers

Thanks for the pointer, for some reason I have missed this paper.
I will address this as well as other comments in a separate email.

/Ingemar

From: Piers O'Hanlon [mailto:[email-masked]]
Sent: den 24 juli 2014 11:03
To: Zaheduzzaman Sarker
Cc: Ingemar Johansson S; [email-masked]; rmcat WG
Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc

Hi Zahed,

On 23 Jul 2014, at 19:31, Zaheduzzaman Sarker wrote:

Hi Piers,
Thanks for the comments.
Could you please send us pointers to the research papers you mentioned in your reply regarding performance issue with "media on hold" in the wireline network?.

I was talking about the suggestions of related approaches such as the use of gaps (RFC6817 Sec 4.4) or 'Random window dropping' (section V.B) in "The quest for LEDBAT fairness, Giovanna Carofiglio, Luca Muscariello, Dario Rossi and Silvio Valenti, Globcom 2010. As mentioned in the paper the utility of media on hold type of approaches is inversely related to the number of flows.

Piers

BR

Zahed

From: Piers O'Hanlon [mailto:[email-masked]]
Sent: den 23 juli 2014 08:26
To: Ingemar Johansson S
Cc: Zaheduzzaman Sarker; [email-masked]<mailto:[email-masked]>; rmcat WG
Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc

Hi Ingemar,

Thanks for your replies - more inline.

Regards,

Piers.

On 17 Jul 2014, at 19:53, Ingemar Johansson S wrote:

Hi

Thanks for the interest in this contribution. Answers/comments inline.

Regards
Ingemar

From: Piers O'Hanlon [mailto:[email-masked]]
Sent: den 17 juli 2014 13:24
To: Ingemar Johansson S; Zaheduzzaman Sarker
Cc: [email-masked]<mailto:[email-masked]>; rmcat WG
Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc

Hi Ingemar and Zahed,

Great to see this work come to draft stage - I like the name. The approach looks interesting - I had a couple of questions:

- Since Scream is based upon LEDBAT I wondered if you had looked into some of the issues it suffers from like; intra-procotol fairness, late-comer advantage, delay-impact on other flows, and yielding behaviour to short of longer lived TCP flows etc.
[IJ] Zahed will present a few test cases at the RMCAT WG sessions. A few additional comments. Yes, I have see similar issues that are reported for LEDBAT in terms of late comers advantage etc. also in SCReAM, the current solution to this is to put media on hold for about one RTT at regular intervals if the one way delay exceeds a threshold and measure the OWD during that period.
This makes it possible to updated the base delay, and also competing LEDBAT based flows will update the base delay more accurately even though they don't use this solution. The behavior in the precense of competing TCP flows depend much on the type of AQM in the bottleneck, a few examples will be given in the presentation.

I guess this sort of technique may be more likely to work in LTE type of environments where each bearer channel only carries a few flows. But on wired links with more flows some research papers seem to show it may not be as effective? I wonder if there's an AQM that more suited to LEDBAT/Vegas style OWD measurement...? I suppose the 'low delay' AQMs would be beneficial but if you're running one of those then most protocols will benefit in terms of low delay.

And also I assume that it's behaviour would be similar to LEDBAT when competing with TCP type flows?

- It is mentioned that there's an 'Adaptive delay target' - but in the code owdTarget does not change - Did you have strategies for choosing the TARGET delay on different links - or is it fixed? Or did you mean the adaptation based on off_target?
[IJ] Correct, there is not yet any adaptive target delay functionality in the code, the adaptive delay target function use the same technique to put the media on hold and measure the OWD during that time and update the delay target. If there are no competing flows then the OWD will drop considerably, if there are competing flows then the OWD will not drop that much, and this is an indication that the delay target can be increased.
Ah ok - Do you see any strange behaviour where different flows end up with different targets and suffer or do they correct themselves quickly enough?

- What period do use to measure the Base Delay (or do use LEDBAT's 1 minute value) - the default seems quite high for mobile deployments...?
[IJ] Don't remember right now but it is definitely shorter than default LEDBAT, will look it up when I am back from the vacation for good in mid August
It would be interesting to know how the actual RTT of on LTE can vary as a user moves, and I imagine handovers would lead to some complications.

- What sort of filtering do you propose for queuing delay beyond MIN - Mobile provides for very noisy environments I wondered if you had any alternatives?
[IJ] Yes it is noisy but sofar I don't use any filtering at all, seems like it is sufficient with the filtering that is inherent in the CWND adjustment.
I guess it depends on the variation of the noise - what sort of variation do you typically see?

- How does it compete against a LEDBAT flow with a similar target?
[IJ] We don't have any example of it, I tried it out in the earlier stages but the results are lost and it is probably better to re run and see how it behaves.
Yes it would be interesting to see how it compares to LEDBAT and to aid in understanding the advantages Scream brings.

Cheers,

Piers

On 17 Jun 2014, at 18:35, Ingemar Johansson S wrote:

Hi

This draft can be of interest for those of you interested in congestion control for realtime media.
http://www.ietf.org/internet-drafts/draft-johansson-rmcat-scream-cc-00.txt

Abstract : "This memo describes a rate adaptation framework for conversational
   video services.  The solution conforms to the packet conservation
   principle and uses a hybrid loss and delay based congestion control
   algorithm.  The framework is evaluated over both simulated bottleneck
   scenarios as well as in a LTE (Long Term Evolution) system simulator
   and is shown to achieve both low latency and high video throughput in
   these scenarios"

/Ingemar

=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com<x-msg://1596/www.ericsson.com>

"The difference between stupidity and
genius is that genius has its limits."
Albert Einstein
=================================

_______________________________________________
iccrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/iccrg