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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 22 July 2015 09:06 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 101511ACEDB for <rmcat@ietfa.amsl.com>; Wed, 22 Jul 2015 02:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 rxgu94B8GDEa for <rmcat@ietfa.amsl.com>; Wed, 22 Jul 2015 02:06:51 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4BD1AD082 for <rmcat@ietf.org>; Wed, 22 Jul 2015 02:06:50 -0700 (PDT)
X-AuditID: c1b4fb2d-f79176d00000321c-2d-55af5d28d89c
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.1B.12828.82D5FA55; Wed, 22 Jul 2015 11:06:48 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.70]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Wed, 22 Jul 2015 11:06:47 +0200
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Michael Welzl <michawe@ifi.uio.no>, "Karen E. E. Nielsen" <karen.nielsen@tieto.com>
Thread-Topic: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
Thread-Index: AQHQuwjSUvgGEfog+E+ekiHUB7EKeJ3ajoow///+aACAADbkAIAAqcECgAbNowCAAPk8AIAAjsAAgAAqLYCAA1ciwA==
Date: Wed, 22 Jul 2015 09:06:47 +0000
Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34B4AA2F@ESESSMB205.ericsson.se>
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>
In-Reply-To: <35276229-26A3-4E8F-ACFB-253A9B6FF26A@ifi.uio.no>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3Rlcjdn2owfk9khaHWmeyWPw4u5PV YsPqKSwWq29+YHNg8Viy5CeTx+rVD5k9Dj0P8jj24StbAEsUl01Kak5mWWqRvl0CV8bbc/NZ CyYqVbQ1P2dpYLwk3cXIySEhYCKx+MpCVghbTOLCvfVsXYxcHEICRxkl9ryexgzhLGaUuNP/ hR2kik3ARmLloe+MILaIQKTEt7OrWUGKmAUeMkr8+TWZBSQhDFTU/qafFaLIVuLkn+VMEHaW xIG+M2BxFgFViWe3zoPV8wr4SnyYuQlq2wtmiUsPbrCBJDgF7CSWTl0EtplRQFbi/vd7YA3M AuISt57MZ4K4W0BiyZ7zzBC2qMTLx/+g/lGSWHt4O1S9nsSNqVPYIGxtiWULXzNDLBaUODnz CcsERrFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtrBLb91 dzCufu14iFGAg1GJh1fh57pQIdbEsuLK3EOM0hwsSuK8MzbnhQoJpCeWpGanphakFsUXleak Fh9iZOLglGpgnL3ollea3nXZP+IbourWfb51NsNumkOAdBa7o9TyJvOijkD38ywZJy5pcGn+ ktUJnHkscKrBsvWfvT813tl+M7w38LR6oGm6h0aFUZee69Kq30HVNQKHLy3dFTNl+n6X67/c evcXzOl2dEnb8fafu4XRgdVpJdr3eSaI/59XUhD+7Q/Dl9/5SizFGYmGWsxFxYkAPs2dPJYC AAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/gy4QzwekcAggGQC8FfUEeLDUEYk>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "rmcat@ietf.org" <rmcat@ietf.org>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
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: Wed, 22 Jul 2015 09:06:53 -0000

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