Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Fri, 31 July 2015 07:31 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F67F1B32D4 for <rmcat@ietfa.amsl.com>; Fri, 31 Jul 2015 00:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cym5YXXqxdyH for <rmcat@ietfa.amsl.com>; Fri, 31 Jul 2015 00:31:32 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED971B32D3 for <rmcat@ietf.org>; Fri, 31 Jul 2015 00:31:31 -0700 (PDT)
X-AuditID: c1b4fb30-f79706d000007227-42-55bb2451da5e
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.E3.29223.1542BB55; Fri, 31 Jul 2015 09:31:29 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.70]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 09:31:26 +0200
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Michael Welzl <michawe@ifi.uio.no>
Thread-Topic: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
Thread-Index: AQHQuwjSUvgGEfog+E+ekiHUB7EKeJ3ajoow///+aACAADbkAIAAqcECgAbNowCAAPk8AIAAjsAAgAAqLYCAA1ciwP//4geAgAM8FiD//+NBAAAEo4fAASxm34AABZKoIP//8hWA//8+0tCAAiQLFQ==
Date: Fri, 31 Jul 2015 07:31:25 +0000
Message-ID: <8yysa9u4qxydnc7snuuon5ay.1438327885021@email.android.com>
References: <559FB533.5090105@tik.ee.ethz.ch> <81564C0D7D4D2A4B9A86C8C7404A13DA34B3AE0B@ESESSMB205.ericsson.se> <55A4CD90.4020905@ericsson.com> <,> <17a463d7eb4dddb627d9d52d0e6ceb2d@mail.gmail.com> <pqd7y09y2g7ct1c7xah2lp1e.1436904929881@email.android.com> <456f0d239cbead1c87a3d639688f7495@mail.gmail.com> <E0F7A68B07B53F4FBD12DABD61CBA90E129ACF5C@ESESSMB307.ericsson.se> <07529396e89526f834a8816d1d2502c7@mail.gmail.com> <35276229-26A3-4E8F-ACFB-253A9B6FF26A@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA34B4AA2F@ESESSMB205.ericsson.se> <248FA5A9-1B0E-4ED1-8D51-CA1487E7ABBF@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA34B4C46D@ESESSMB205.ericsson.se> <44A520B8-4DEC-4D9C-97DE-5223DD8A4CB0@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA34B4C4DB@ESESSMB205.ericsson.se> <55B9FD05.1050807@tik.ee.ethz.ch> <81564C0D7D4D2A4B9A86C8C7404A13DA34B4EACB@ESESSMB205.ericsson.se> <55BA16BF.6030101@tik.ee.ethz.ch>, <81564C0D7D4D2A4B9A86C8C7404A13DA34B4FCF5@ESESSMB205.ericsson.se>
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA34B4FCF5@ESESSMB205.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW6gyu5Qgz3b5SwOtc5ksfhxdier xYbVU1gsVt/8wObA4rFkyU8mj9WrHzJ7HHoe5HHsw1e2AJYoLpuU1JzMstQifbsErozW7vVs BevSKn5vn8zSwNgV3MXIySEhYCLxp3kuG4QtJnHh3nogm4tDSOAoo8T2VbdZIZzFjBLrjp5n AaliE7CRWHnoOyOILSKQJ9E5ZwoLSBGzwClGiYnL5jCBJISBilZ9ugtVZCtx8s9yJpAiEYFl jBI3f05lBkmwCKhK/LnSBlTEwcEr4CZx4Uw1xLZX7BJX/v4D28Yp4CexsnM12FBGAVmJ+9/v gcWZBcQlPs99wARxt4DEkj3nmSFsUYmXj/+xQtToSdyYOoUNwtaWWLbwNVgNr4CgxMmZT1gm MIrOQjJqFpKWWUhaZiFpWcDIsopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMKYObvltsIPx 5XPHQ4wCHIxKPLwLru0KFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRjMu75Vy04prVPYxpu7Yq/qOJehSyKXnKh36Ghn/dqY8SbwW/JjnnPXs7nDFY2wW vJ2PHN7zlcY5xH7xX7C9O+H0/pm/fKo5s8TaFjNIXT0cozNRS+q+jOgC6xSBENGO+5PXJbzR nz/txOzFf4ovGlytS/pydHtqzorP9wKapF7wTXp3zSt+hRJLcUaioRZzUXEiALrtruSKAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/iMEr7iKgPhkMy03KmneDvxLseLM>
Cc: "Karen E. E. Nielsen" <karen.nielsen@tieto.com>, "rmcat@ietf.org" <rmcat@ietf.org>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 07:31:35 -0000

Errata... Should be "not convinced about the name change", thanks for the heads up Zahed :-)

...But if it is needed in order to get a common set of terms

Sent from Moxier Mail
(http://www.moxier.com)


----- Ursprungligt meddelande -----
Från: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Till: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Michael Welzl <michawe@ifi.uio.no>
Kopia: "Karen E. E. Nielsen" <karen.nielsen@tieto.com>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, "rmcat@ietf.org" <rmcat@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Skickat: 2015-07-31 0:30
Ämne: RE: [rmcat] Review of draft-ietf-rmcat-scream-cc-01



Hi

The term transmission scheduler was taken from a discussion on the TCPM WG (thread starts at http://www.ietf.org/mail-archive/web/tcpm/current/msg08768.html ), the definition was borrowed from TCP laminar. This means that I am currently convinced about the name change.
The RTP packets from two or more streams (RTP queues) are in its simplest form picked in a round-robin fashion. This is described in section 4.1. If prioritization is desired then a credit based system is used, described in appendix A.2. In reality the credit based approach is always enabled even though no prioritization between streams is applied, in this case all streams get the same priority.
It is imperative however that all streams are able to transmit RTP packets frequently. This to avoid extra queueing delay on the sender side. With a 2:1 prioritization allocation, one stream gets to send 2 RTP packets, then the other stream gets to send 1 RTP packet.
It is for instance not too practical to allow one stream to send for 100ms and then let the other stream transmit for 50ms, this will only increase latency and risk making the video choppy. This is the main reason why SCReAMs transmit scheduling and prioritization operates is RTP packet transmission clocked instead of timer based.
But...of course one can implement timer based prioritization with shorter intervals, in which case the differences would be smaller, but for SCReAM it is more practical to be RTP packet transmission based.

PS, deliberately omitted the fact than one (or even all streams) may have nothing to transmit, this is handled in the code however.  For those interested, it is possible to experiment with the C++ code to see how the stream prioritization performs.


/Ingemar



> -----Original Message-----
> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> Sent: den 30 juli 2015 14:21
> To: Ingemar Johansson S; Michael Welzl
> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; rmcat@ietf.org
> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
>
> Hi Ingemar,
>
> okay thanks for the clarification. I discussed this with Zahed and the
> scheduler as described in section 4.1.2.2. should probably be renamed to
> something like sending rate controller because without the prioritization it's
> only handling one flow at a time, right?
>
> Mirja
>
>
> On 30.07.2015 13:22, Ingemar Johansson S wrote:
> > Hi
> >
> > Probably needs some clarification. The transmission scheduler that decides
> when to transmit RTP packets is an integral part of SCReAM and described in
> section 4.1.2.2 in the draft.
> > Stream prioritization is applied when two or more streams share a
> congestion control and is described in section A.2.
> >
> > The former has been evaluated earlier , the latter is only exemplified
> > in
> > https://github.com/EricssonResearch/scream/blob/master/SCReAM-
> descript
> > ion.pdf
> >
> > The evaluation of stream prioritization leads to a set of follow-up
> questions. What kind of source behavior do be assume, is it CBR  or VBR.
> Stream prioritization of CBR sources is quite trivial to solve IMO, VBR is more
> complicated.
> >
> > /Ingemar
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> >> Sent: den 30 juli 2015 12:32
> >> To: Ingemar Johansson S; Michael Welzl
> >> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; rmcat@ietf.org
> >> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> >>
> >> Hi Ingemar,
> >>
> >> A quick comment here:
> >>
> >>> I think however the scheduling it will remain in the running code
> >>> (C++ code
> >> and OWR) at least until a good alternative is available.
> >>
> >> If the scheduling stays in the appendix, we definitely need to see
> >> evaluation results for Scream without scheduling. If scheduling is an
> >> essential part of Scream, you also need a shared bottleneck
> >> detection! Actually I guess we need to see evaluation results for
> >> Scream without scheduling in any case, because there might always be
> >> the case where the sbd does not detect a shared bottleneck correctly.
> >>
> >> Mirja
> >>
> >>
> >>
> >>>
> >>> /Ingemar
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Michael Welzl [mailto:michawe@ifi.uio.no]
> >>>> Sent: den 24 juli 2015 10:57
> >>>> To: Ingemar Johansson S
> >>>> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; rmcat@ietf.org; Mirja
> >>>> Kühlewind
> >>>> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> >>>>
> >>>> No.
> >>>>
> >>>> Our algo lets you assign priorities, and they are valid at the time
> >>>> you set them, they just give you a portion of the overall rate and
> >>>> it applies as soon as you set it.
> >>>> If  you want to adjust priorities based on the coder output rate
> >>>> variation, you can implement this using our algo or with a scheduler.
> >>>> A scheduler operates per packet, we operate per time, so
> >> implementation-wise it's a bit different.
> >>>>
> >>>> My point is only: whether you do it with our algorithm or without a
> >>>> scheduler, I think this should not be in our draft  (and I'm neutral about:
> >>>> should it be in the SCReAM draft or separate from it).
> >>>>
> >>>> Cheers,
> >>>> Michael
> >>>>
> >>>>
> >>>>> On 24. jul. 2015, at 10.42, Ingemar Johansson S
> >>>> <ingemar.s.johansson@ericsson.com> wrote:
> >>>>>
> >>>>> Hi
> >>>>>
> >>>>> Not sure I get it.
> >>>>> Do you mean that coupling algo is immune to video coder output
> >>>>> rate
> >>>> variation ?
> >>>>>
> >>>>> /Ingemar
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Michael Welzl [mailto:michawe@ifi.uio.no]
> >>>>>> Sent: den 22 juli 2015 11:16
> >>>>>> To: Ingemar Johansson S
> >>>>>> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; rmcat@ietf.org;
> >>>>>> Mirja Kühlewind
> >>>>>> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> >>>>>>
> >>>>>> understood; i think these details are beyond the scope of our
> >>>>>> coupling draft which focuses on a different method.
> >>>>>>
> >>>>>> cheers
> >>>>>> michael
> >>>>>>
> >>>>>> Sent from my iPhone
> >>>>>>
> >>>>>>> On 22. juli 2015, at 11:06, Ingemar Johansson S
> >>>>>> <ingemar.s.johansson@ericsson.com> wrote:
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Still waiting for the summer to show up so I'll try to chime in
> >>>>>>> while this
> >>>>>> subject is at least luke-warm. I may be slow with follow up on
> >>>>>> this, sorry for that in advance.
> >>>>>>>
> >>>>>>> Stream prio in SCReAM is outlined in section A.2 in the draft
> >>>>>> (https://tools.ietf.org/html/draft-ietf-rmcat-scream-cc-01#page-28
> ).
> >>>>>> In its function it resembles fq-codel quite a lot in the sense
> >>>>>> that streams that do not get scheduled at a given scheduling
> >>>>>> instant gets a credit that is used to increase the chance of
> >>>>>> being scheduled at the next scheduling instant. A configurable
> >>>>>> scheduling priority determines
> >>>> how much credit  that is given.
> >>>>>> Looking in the
> >>>>>> https://tools.ietf.org/pdf/draft-ietf-tsvwg-sctp-ndata-04.pdf
> >>>>>> draft I would say that this resembles the "Weighted Fair Queueing
> >>>>>> Scheduler"  the most. Some additional means are needed to make
> >>>>>> this work well in reality though (see below).
> >>>>>>>
> >>>>>>> The benefit with doing scheduling priority and a common
> >>>>>>> congestion
> >>>>>> control is an increased probability that the path capacity is
> >>>>>> fully utilized, if a stream becomes idle (for instance no or
> >>>>>> little activity in one video source) , more resources are
> >>>>>> allocated to the other sources. And this is achieved with no or
> >>>>>> very little additional delay
> >>>> buildup on the sender side.
> >>>>>>> Another benefit with stream prioritization is that it is easier
> >>>>>>> to make one
> >>>>>> congestion control behave well (low delay /packet loss) esp. on a
> >>>>>> wireless link. We have simulation results that supports this
> >>>>>> statement albeit in the different context (QUIC congestion
> >>>>>> control
> >>>> evolution).
> >>>>>>> The stream prioritization and one congestion control of course
> >>>>>>> require that all the streams share the same bottleneck
> >>>>>>> characteristics
> >>>>>>>
> >>>>>>> With that said, the biggest challenge I have seen this far is
> >>>>>>> the large
> >>>>>> variability of esp. video sources. Sit still in front of the
> >>>>>> camera and the output rate becomes very low regardless the target
> >>>>>> rate, move yourself closer to the camera and bang!!.. you get
> >>>>>> 2Mbps video rate all of a sudden. This variability causes issues
> >>>>>> with stream prioritization in the sense that less variable
> >>>>>> streams may be pushed back. Additional code is therefore added in
> >>>>>> SCReAM to correct this anomaly and ensure a (weighted) fair
> >>>>>> distribution over a longer time scale. Still as mentioned in the
> >>>>>> SCReAM draft, this needs to be tried out some more. I have sofar
> >>>>>> only simulated video sources with variability
> >>>> to see that the current implementation is reasonably robust.
> >>>>>>> The bottom line here is that, while scheduling of streams with
> >>>>>>> static
> >>>>>> properties may be considered simple, real video may be a taller
> order.
> >>>>>>>
> >>>>>>> /Ingemar
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Michael Welzl [mailto:michawe@ifi.uio.no]
> >>>>>>>> Sent: den 20 juli 2015 10:03
> >>>>>>>> To: Karen E. E. Nielsen
> >>>>>>>> Cc: Zaheduzzaman Sarker; Ingemar Johansson S; rmcat@ietf.org;
> >>>>>>>> Mirja Kühlewind
> >>>>>>>> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> On 20. jul. 2015, at 07.32, Karen Elisabeth Egede Nielsen
> >>>>>>>>> <karen.nielsen@tieto.com> wrote:
> >>>>>>>>>
> >>>>>>>>> HI,
> >>>>>>>>>
> >>>>>>>>> Yes - there is the possibility to implement coupled congestion
> >>>>>>>>> control with scheduling priorities, There is no doubt about
> >>>>>>>>> that :-), Indeed SCTP does it and scream does it.
> >>>>>>>>> But it is not so well-described in the scream draft how
> >>>>>>>>> exactly the prioritization works and which means an
> >>>>>>>>> application has to define different priorities.
> >>>>>>>>> (For information then for SCTP a number of different
> >>>>>>>>> scheduling possibilities is described in
> >>>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/.)
> >>>>>>>>>
> >>>>>>>>> Then for RMCAT coupled congestion control  we have the Wezlz,
> >>>>>>>>> Safiqul proposal where the coupled is done in-between per
> >>>>>>>>> flow-CC contexts by prioritization on manipulation of the cwnd.
> >>>>>>>>> And the we also have, a not so detailed proposal/description,
> >>>>>>>>> on how the same can be achieved via scheduling (scream).
> >>>>>>>>> It should be ok to allow for different ways to implement
> >>>>>>>>> coupling, but we should then eventually have one document
> that
> >>>>>>>>> describes both solutions. Shouldn't we ?
> >>>>>>>>
> >>>>>>>> I think so. There is already (short, because it's so simple)
> >>>>>>>> text about scheduling in coupled-cc and we can extend that and
> >>>>>>>> make it stand out more clearly (now it's in the intro I think).
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Michael
> >>>>>>>
> >>>
> >>
> >> --
> >> ------------------------------------------
> >> Dipl.-Ing. Mirja Kühlewind
> >> Communication Systems Group
> >> Institute TIK, ETH Zürich
> >> Gloriastrasse 35, 8092 Zürich, Switzerland
> >>
> >> Room ETZ G93
> >> phone: +41 44 63 26932
> >> email: mirja.kuehlewind@tik.ee.ethz.ch
> >> ------------------------------------------
>
> --
> ------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Communication Systems Group
> Institute TIK, ETH Zürich
> Gloriastrasse 35, 8092 Zürich, Switzerland
>
> Room ETZ G93
> phone: +41 44 63 26932
> email: mirja.kuehlewind@tik.ee.ethz.ch
> ------------------------------------------