From nobody Wed Jul 2 05:15:03 2014 Return-Path: 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 D307F1A0091 for ; Wed, 2 Jul 2014 05:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CVB1jTONhBzr for ; Wed, 2 Jul 2014 05:14:58 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063821A008C for ; Wed, 2 Jul 2014 05:14:58 -0700 (PDT) Received: from [130.209.247.112] (port=63249 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X2JR9-0000Yo-HU for rmcat@ietf.org; Wed, 02 Jul 2014 13:14:56 +0100 From: Colin Perkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Jul 2014 13:14:52 +0100 References: <20140702115009.7506.80609.idtracker@ietfa.amsl.com> To: rmcat WG Message-Id: <152642DB-524C-409E-A7D3-18BC8A8F69ED@csperkins.org> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/gcYl-BGa0uYeZoM9ySmDYSBQ1hs Subject: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 12:15:01 -0000 This draft discusses what congestion control feedback is achievable with = RTCP. I presented the initial version to RMCAT at IETF 86. This version = updates Section 3.2 based on discussion with Magnus Westerlund, to give = more accurate recommendations on the session bandwidth needed to allow = per-frame RTCP feedback. I don=92t think this needs agenda time at IETF 90, but is rather = provided to inform the design of the congestion control feedback = proposals.=20 Colin Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt > Date: 2 July 2014 12:50:09 BST > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Using RTP Control Protocol (RTCP) Feedback = for Unicast Multimedia Congestion Control > Author : Colin Perkins > Filename : draft-perkins-rmcat-rtp-cc-feedback-01.txt > Pages : 8 > Date : 2014-07-02 >=20 > Abstract: > This memo discusses the types of congestion control feedback that it > is possible to send using the RTP Control Protocol (RTCP), and their > suitability of use in implementing congestion control for unicast > multimedia applications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-perkins-rmcat-rtp-cc-feedback-01 --=20 Colin Perkins http://csperkins.org/ From nobody Thu Jul 3 00:11:56 2014 Return-Path: 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 589B61A007A for ; Thu, 3 Jul 2014 00:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 M_rIC5m91KaO for ; Thu, 3 Jul 2014 00:11:52 -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 6B8E91A006F for ; Thu, 3 Jul 2014 00:11:51 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-7a-53b50235e128 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.2B.03739.53205B35; Thu, 3 Jul 2014 09:11:49 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 09:11:48 +0200 From: Ingemar Johansson S To: Colin Perkins , rmcat WG Thread-Topic: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt Thread-Index: AQHPligX/2ruE2+RUk647PIUkuOv1ZuN6F9w Date: Thu, 3 Jul 2014 07:11:48 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7186@ESESSMB205.ericsson.se> References: <20140702115009.7506.80609.idtracker@ietfa.amsl.com> <152642DB-524C-409E-A7D3-18BC8A8F69ED@csperkins.org> In-Reply-To: <152642DB-524C-409E-A7D3-18BC8A8F69ED@csperkins.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7186ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RteUaWuwwdzvOhbLX55gtFh98wOb A5PHtPv32TyWLPnJFMAUxWWTkpqTWZZapG+XwJVxdKpkwd7QijOrPjM2MHZ4djFycEgImEi8 vSzWxcgJZIpJXLi3nq2LkYtDSOAoo8SzqT9YIJxFjBL3uiewgVSxCdhIrDz0nRHEFhFwkHiy ZTMziM0sYCXx5fhfMFtYIEhi3uT1LBA1wRLNS2ayQthGEpfvTGQGWcwioCJxYrMcSJhXwFfi 975esJFCAuUS6/fPYQexOQUcJV63zAJrZRSQlbj//R4LxCpxiVtP5jNBHC0gsWTPeWYIW1Ti 5eN/rBC2kkTjkiesEPX5EituTWKB2CUocXLmE5YJjKKzkIyahaRsFpIyiLiOxILdn9ggbG2J ZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMNYObvmtu4Nx9WvH Q4wCHIxKPLwLPLYEC7EmlhVX5h5ilOZgURLnXXRuXrCQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGRmEBq6nm/Cfk4nNld58o57J4ZfZl51X1ToPHUzOSlVcaz343Z9LZyTnPpWX9P8vvclo1 hye4e4vBu7gfLlyZC9tLPqlvLzkm5yx6pC75I09SysvtP1eu7526SWPXyXg3d68zjLwPF37I fNM5c3PhinMNxSyvIg5NEArmP1l/PznzYHP8efl7/5RYijMSDbWYi4oTAbDs5wOWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/n3ie4VaGyawopxwwbT75dYh_1dM Cc: Ingemar Johansson S Subject: Re: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 07:11:55 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7186ESESSMB205erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have experimented a bit with ack clocked algorithms for rate adaptation (= in simulator). Originally I implemented it as something that required an ex= tra layer with per packet feedback between RTP and UDP, this is briefly des= cribed in Nikolas Hermanns master thesis * SCReAM ** is however based on RTCP feedback, in order to keep the RTCP feed= back overhead limited it is recommended to use reduced size RTCP with trans= mission of full compund RTCP every T_rr_interval. The feedback in the curre= nt implementation transmits feedback as often as possible but it is actuall= y AVPF regular mode transmission, I have found out that in practice I end u= p with one feedback roughly every video frame internal. The feedback thus r= esembles TCPs delay ACK mechanisms. And it seems to work fine. I suspect ho= wever that there is an increased risk that coalescing (or is it called ACK = compression) effects are amplified. I will later on investigate if this a p= roblem in reality and if Immediate mode tranmission improves things. I would not recommend to use per frame feedback with SCReAM, a single lost = packet means that an entire video frame is discarded with the effect that n= o feedback is transmitted (for that frame). This can make the ack-clocking = to hickup, not sure if it is a serious problem but believe that the per pac= ket feedback limited by the AVPF regular mode timing is safer. /Ingemar *http://www.lauritshamm.de/MediaRateAdaptationConversationalVideoServicesNe= xtGenerationMobileNetworks_Hermanns_2013_Thesis.pdf ** http://tools.ietf.org/id/draft-johansson-rmcat-scream-cc-02.txt > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 2 juli 2014 14:15 > To: rmcat WG > Subject: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.= txt > > This draft discusses what congestion control feedback is achievable with > RTCP. I presented the initial version to RMCAT at IETF 86. This version > updates Section 3.2 based on discussion with Magnus Westerlund, to give > more accurate recommendations on the session bandwidth needed to allow > per-frame RTCP feedback. > > I don't think this needs agenda time at IETF 90, but is rather provided t= o > inform the design of the congestion control feedback proposals. > > Colin > > > > > Begin forwarded message: > > From: internet-drafts@ietf.org > > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt > > Date: 2 July 2014 12:50:09 BST > > To: i-d-announce@ietf.org > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Using RTP Control Protocol (RTCP) Feedback for= Unicast > Multimedia Congestion Control > > Author : Colin Perkins > > Filename : draft-perkins-rmcat-rtp-cc-feedback-01.txt > > Pages : 8 > > Date : 2014-07-02 > > > > Abstract: > > This memo discusses the types of congestion control feedback that it > > is possible to send using the RTP Control Protocol (RTCP), and their > > suitability of use in implementing congestion control for unicast > > multimedia applications. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-perkins-rmcat-rtp-cc-feedback-= 01 > > > -- > Colin Perkins > http://csperkins.org/ > > > --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7186ESESSMB205erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
I have experimented a bit with ack clocked algorithms for rate adaptat= ion (in simulator). Originally I implemented it as something that required = an extra layer with per packet feedback between RTP and UDP, this is briefl= y described in Nikolas Hermanns master thesis *
SCReAM ** is however based on RTCP feedback, in order to keep the RTCP= feedback overhead limited it is recommended to use reduced size RTCP with = transmission of full compund RTCP every T_rr_interval. The feedback in the = current implementation transmits feedback as often as possible but it is actually AVPF regular mode transmis= sion, I have found out that in practice I end up with one feedback roughly = every video frame internal. The feedback thus resembles TCPs delay ACK mech= anisms. And it seems to work fine. I suspect however that there is an increased risk that coalescing (or is it= called ACK compression) effects are amplified. I will later on investigate= if this a problem in reality and if Immediate mode tranmission improves th= ings.
I would not recommend to use per frame feedback with SCReAM, a single = lost packet means that an entire video frame is discarded with the effect t= hat no feedback is transmitted (for that frame). This can make the ack-cloc= king to hickup, not sure if it is a serious problem but believe that the per packet feedback limited by the A= VPF regular mode timing is safer.
 
/Ingemar   
 
 
> -----Original Message-----
> From: Colin Perkins [mailto:= csp@csperkins.org]
> Sent: den 2 juli 2014 14:15
> To: rmcat WG
> Subject: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feed= back-01.txt
>
> This draft discusses what congestion control feedback is achievab= le with
> RTCP. I presented the initial version to RMCAT at IETF 86. This v= ersion
> updates Section 3.2 based on discussion with Magnus Westerlund, t= o give
> more accurate recommendations on the session bandwidth needed to = allow
> per-frame RTCP feedback.
>
> I don’t think this needs agenda time at IETF 90, but is rat= her provided to
> inform the design of the congestion control feedback proposals.
>
> Colin
>
>
>
>
> Begin forwarded message:
> > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.= txt
> > Date: 2 July 2014 12:50:09 BST
> >
> >
> > A New Internet-Draft is available from the on-line Internet-= Drafts
> directories.
> >
> >
> >        Title  &= nbsp;        : Using RTP Control Protoco= l (RTCP) Feedback for Unicast
> Multimedia Congestion Control
> >        Author  =         : Colin Perkins
> >      Filename   &nbs= p;    : draft-perkins-rmcat-rtp-cc-feedback-01.txt
> >      Pages    &= nbsp;      : 8
> >      Date    &n= bsp;       : 2014-07-02
> >
> > Abstract:
> >   This memo discusses the types of congestion cont= rol feedback that it
> >   is possible to send using the RTP Control Protoc= ol (RTCP), and their
> >   suitability of use in implementing congestion co= ntrol for unicast
> >   multimedia applications.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> > There's also a htmlized version available at:
> >
> > A diff from the previous version is available at:
>
>
> --
> Colin Perkins
>
>
>
 
 
 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7186ESESSMB205erics_-- From nobody Thu Jul 3 02:08:56 2014 Return-Path: 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 B8C421B27EC for ; Thu, 3 Jul 2014 02:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no 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 FfWpgVspSU5K for ; Thu, 3 Jul 2014 02:08:49 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30071B27CC for ; Thu, 3 Jul 2014 02:08:48 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id CD29560335; Thu, 3 Jul 2014 11:08:46 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9D787601DC; Thu, 3 Jul 2014 11:08:46 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Dave Taht Date: Thu, 3 Jul 2014 11:08:46 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <53AC0DC9.2020803@ericsson.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201407031108.46431.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/TpRnsF81dVpz_3OPN3n8ZoUZrBE Cc: Ingemar Johansson S , rmcat@ietf.org, Zaheduzzaman Sarker Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 09:08:54 -0000 Hi Dave, you definitely bring up a valid point and I believe you that this strategy= =20 helps to reduce your workload. Still I (personally and as chair) would like= =20 to comment on this.=20 =46irst of all, the draft has pseudo code attached which should provide an = easy=20 start to re-implement and re-produce the results. I really appreciate this.= =20 =46urther, this is new work with first results and I personally prefer to h= ave=20 published this early so other people might be aware of this work and can do= =20 an own implementation if they are interested. As a chair I think that it's= =20 actually good to have independent implementations from different people=20 (only) based on the draft because that gives most confident that the draft = is=20 complete and understandable. In the current state of rmcat we are looking f= or=20 independent evaluations to ensure that an algorithm is at least safe to=20 experiment with in the wild. Of course that's easier if there are=20 implementations already available. Anyway the author just started on this=20 work and are planning to provide implementations in future, so that's=20 absolutely the right way to do this. Mirja On Thursday 26 June 2014 19:06:29 Dave Taht wrote: > On Thu, Jun 26, 2014 at 5:10 AM, Zaheduzzaman Sarker > > wrote: > > Hi Luca, > > > > The simulation code is implemented in our proprietary simulator (I shou= ld > > thank my MS thesis workers who contributed a lot). Thus cant really sha= re > > the code but what I can share is some simulation results. > > I have decided that I will no longer consider experimental results > that cannot easily be reproduced independently, and will ignore future > articles, internet drafts, and proposals that do not come with > sufficient source code to reproduce independently. > > Nearly every published experiment that actually supplied sufficient > information, raw data and code to reproduce it - that I've had the > chance to examine closely and/or reproduce in more varied > circumstances - has been flawed, and I have no reason whatsoever to > believe that code I cannot see and run is not flawed in some respect, > either. > > If I apply this criterion as a stage-1 filter, my workload drops > enormously. > > Both chrome and firefox have mostly working webrtc implementations > now, and whatever future algorithms proposed should be able to be > easily hacked into those and tried in real life. > > open source ns2, ns3, and mininet simulators exist as well as a basis > for future work. > > My policy is obviously not the ietf's nor the position of the chairs of > this wg, but it is in the spirit of "rough consensus and running code". > > > Note that in our implementation we followed latest update for varying > > threshold from the GCC draft > > > > If you want GCC related logs particularly for LTE simulations I cant not > > provide that.We simulate lots of users and dont log all the GCC related > > variables. > > > > However, I have attached simulation logs from two test cases- > > 1. a staircase bandwidth test , that I found interesting in one of the > > papers. > > 2. and test case 5.1 from > > http://tools.ietf.org/html/draft-sarker-rmcat-eval-test-01. > > > > I hope those plots will give you an idea about the implementation we ha= ve > > and how it is behaving. > > > > I would suggest you run tests from > > http://tools.ietf.org/html/draft-sarker-rmcat-eval-test-01 as well and > > then we can compare the results. > > > > BR > > > > Zahed > > > > On 2014-06-25 17:32, Luca De Cicco wrote: > >> Dear Zahed, > >> > >> can you share some information about the GCC simulation code? > >> > >> thanks, > >> Luca > >> > >> > >> On Wed, Jun 25, 2014 at 2:46 PM, Ingemar Johansson S > >> >> > wrote: > >> > >> Hi____ > >> > >> __ __ > >> > >> Thanks for the interest in this work. ____ > >> > >> __ __ > >> > >> Crosspost to RMCAT as well, hope that is Ok____ > >> > >> Answers/comments inline____ > >> > >> __ __ > >> > >> /Ingemar____ > >> > >> __ __ > >> > >> *From:*Luca De Cicco [mailto:ldecicco@gmail.com > >> ] > >> *Sent:* den 25 juni 2014 13:23 > >> *To:* Ingemar Johansson S > >> *Cc:* Dave Taht; iccrg@irtf.org > >> *Subject:* Re: [iccrg] draft-johansson-rmcat-scream-cc____ > >> > >> __ __ > >> > >> Dear Ingemar,____ > >> > >> __ __ > >> > >> I have some questions. ____ > >> > >> __ __ > >> > >> > >> 1) In the architecture figure (Figure 2) you show the case of two > >> videos produced by the ____ > >> > >> > >> same source and going to the same destination (both videos are > >> encoded and fed to the same UDP socket),____ > >> > >> > >> am I right? In the case SCReAM is used in a WebRTC context (in a > >> browser), what use case ____ > >> > >> are you imagining?____ > >> > >> > >> [IJ] This was just to highlight how two sources are handled, I am > >> fully aware that it is probably not the most common use case, on t= he > >> other hand I don=E2=80=99t know how WebRTC will be used in the fut= ure. If > >> there are two destinations then one will need to congestion control > >> contexts (one for each UDP socket). The bandwidth distribution may > >> then be based on rate shaping but another, possibly more useful, > >> option is to target the congestion window functions directly, for > >> instance if the congetsion window for one flow is knocked down just > >> a little then the other flow will grab the free capacity > >> automatically. Another option is to adjust the gain factors for the > >> CWND calculations.____ > >> > >> __ __ > >> > >> > >> 2) How did you implement GCC algorithm? Do you have a paper where I > >> can see the dynamics of GCC (for instance____ > >> > >> > >> the rate computed by the receiver side controller, the estimated o= ne > >> way queuing delay variation "m")?____ > >> > >> > >> [IJ] The GCC algorithm was implemented into our simulation platform > >> by Zahed, it is based in the availabe code and the drafts. We have > >> logging possibilities in our simulator but I don=E2=80=99t know of= any paper > >> around this.____ > >> > >> __ __ > >> > >> > >> 3) You show average bitrate in the tables. There's an odd situation > >> where GCC gets a 50% packet loss ratio in the case of____ > >> > >> > >> 16 users/cell but with an average rate of 61 kbps. Can you elabora= te > >> on this?____ > >> > >> > >> [IJ] Could be an effect of a much too high load in combination with > >> a high mobility, could be an effect of large amount of packet loss= es > >> due to network queue overflow. I will BTW update the evaluation > >> results for GCC soon, it seems like it was tuned a but too > >> sensitive, with the new setting one get higher bitrates, but > >> unfortunately also the tail latency will increase more quickly with > >> increased load. ____ > >> > >> __ __ > >> > >> Cheers,____ > >> > >> Luca____ > >> > >> __ __ > >> > >> > >> On Wed, Jun 18, 2014 at 11:37 AM, Ingemar Johansson S > >> >> > wrote:____ > >> > >> > >> Hi > >> > >> Besides the example code there is no ready to compile code availab= le > >> (at least nothing that I know of). But on the other hand the > >> solution has similarities to TFWC (TCP Friendly Window-based > >> Congestion control) that was devised by Soo-Hyun Choi > >> (http://tfwc.hackerslab.eu/ ), perhaps that can be used as a basis= ? > >> > >> /Ingemar____ > >> > >> > -----Original Message----- > >> > From: Dave Taht [mailto:dave.taht@gmail.com > >> > >> ] > >> > >> > Sent: den 17 juni 2014 20:00 > >> > To: Ingemar Johansson S > >> > Cc: iccrg@irtf.org > >> > Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc > >> > > >> > My usual request: Is there running code somewhere? > >> > > >> > On Tue, Jun 17, 2014 at 10:35 AM, Ingemar Johansson S > >> > >> > >> > wrote: > >> > > Hi > >> > > > >> > > > >> > > > >> > > This draft can be of interest for those of you interested in > >> > > congestion control for realtime media. > >> > >> =20 > >> http://www.ietf.org/internet-drafts/draft-johansson-rmcat-scream-cc-00 > >> > >> > > .txt > >> > > > >> > > > >> > > > >> > > Abstract : =E2=80=9CThis memo describes a rate adaptation fra= mework 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=E2=80=9D > >> > > > >> > > > >> > > > >> > > /Ingemar > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > >> > > Ingemar Johansson M.Sc. > >> > > > >> > > Senior Researcher > >> > > > >> > > > >> > > > >> > > Ericsson AB > >> > > > >> > > Wireless Access Networks > >> > > > >> > > Labratoriegr=C3=A4nd 11 > >> > > > >> > > 971 28, Lule=C3=A5, Sweden > >> > > > >> > > Phone +46-1071 43042 > >> > > > >> > > SMS/MMS +46-73 078 3289 > >> > > > >> > > ingemar.s.johansson@ericsson.com > >> > >> > >> > >> > > www.ericsson.com > >> > > > >> > > > >> > > > >> > > > >> > > =E2=80=9CThe difference between stupidity and > >> > > > >> > > genius is that genius has its limits." > >> > > Albert Einstein > >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > _______________________________________________ > >> > > iccrg mailing list > >> > > iccrg@irtf.org > >> > > > >> > > https://www.irtf.org/mailman/listinfo/iccrg > >> > > >> > -- > >> > Dave T=C3=A4ht > >> > > >> > NSFW: > >> > >> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_i= nd > >>ec > >> > >> > ent.article > >> > >> _______________________________________________ > >> iccrg mailing list > >> iccrg@irtf.org > >> https://www.irtf.org/mailman/listinfo/iccrg____ > >> > >> __ __ > > > > -- > > > > Zahed > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > ANM ZAHEDUZZAMAN SARKER > > > > > > Ericsson AB > > Services, Media and Network Features > > Laboratoriegr=C3=A4nd 11 > > 97128 Lule=C3=A5, Sweden > > Phone +46 10 717 37 43 > > Fax +46 920 996 21 > > SMS/MMS +46 76 115 37 43 > > zaheduzzaman.sarker@ericsson.com > > www.ericsson.com > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=C3=BChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From nobody Thu Jul 3 04:42:43 2014 Return-Path: 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 2799C1B28E0 for ; Thu, 3 Jul 2014 04:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] 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 4TRc2mkdV4cB for ; Thu, 3 Jul 2014 04:42:36 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80701B28DA for ; Thu, 3 Jul 2014 04:42:35 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 779D2601E3 for ; Thu, 3 Jul 2014 13:42:34 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 74DA2601E2 for ; Thu, 3 Jul 2014 13:42:34 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: rmcat@ietf.org Date: Thu, 3 Jul 2014 13:42:34 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201407031342.34353.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/OLUmtE-OvAZooancsCdGg75GkbQ Subject: [rmcat] Draft agenda 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 11:42:37 -0000 Hi w-g, I've upload a first draft of our agenda: http://www.ietf.org/proceedings/90/agenda/agenda-90-rmcat Please let me know if you think there are any changes needed (in ordering or timing or whatever)! I've put all presentations with evaluation results in the second slot, which is (only) one hour. I hope that's sufficient time including discussions..., Mirja From nobody Fri Jul 4 11:11:09 2014 Return-Path: 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 B69E71B2DCB; Fri, 4 Jul 2014 11:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8acha838dw7S; Fri, 4 Jul 2014 11:10:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8E11B2B4D; Fri, 4 Jul 2014 11:10:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704181059.16509.12030.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 11:10:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/mwAOSS94_YX0dkotbG74d3ve2UI Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:11:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Congestion Control Requirements For RMCAT Author : Randell Jesup Filename : draft-ietf-rmcat-cc-requirements-05.txt Pages : 9 Date : 2014-07-04 Abstract: Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for realtime media congestion avoidance technique. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 11:12:59 2014 Return-Path: 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 D583F1B2DBA for ; Fri, 4 Jul 2014 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 mOTQkMZjukCe for ; Fri, 4 Jul 2014 11:12:48 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37ABC1B2E01 for ; Fri, 4 Jul 2014 11:12:44 -0700 (PDT) Received: from pool-173-49-136-114.phlapa.fios.verizon.net ([173.49.136.114]:49197 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X37yV-0006ox-Hk for rmcat@ietf.org; Fri, 04 Jul 2014 13:12:43 -0500 Message-ID: <53B6EE8E.6030608@jesup.org> Date: Fri, 04 Jul 2014 14:12:30 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <20140704181059.16509.12030.idtracker@ietfa.amsl.com> In-Reply-To: <20140704181059.16509.12030.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/HvSWw8xpSZ16h689dqEwCuUoZx8 Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-05.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:12:56 -0000 On 7/4/2014 2:10 PM, internet-drafts@ietf.org wrote: > Title : Congestion Control Requirements For RMCAT > Author : Randell Jesup > Filename : draft-ietf-rmcat-cc-requirements-05.txt > Pages : 9 > Date : 2014-07-04 > This is solely a nit-cleanup response to Spencer Dawkin's comments. No substantive changes. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Sun Jul 6 14:54:11 2014 Return-Path: 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 1DBF61A0AB0 for ; Sun, 6 Jul 2014 14:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 eGu5k1IlPNXz for ; Sun, 6 Jul 2014 14:54:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261CA1A0AAB for ; Sun, 6 Jul 2014 14:54:06 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-46-53b9c57b4ada Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.60.19155.B75C9B35; Sun, 6 Jul 2014 23:54:03 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Sun, 6 Jul 2014 23:54:03 +0200 From: Ingemar Johansson S To: "varun@comnet.tkk.fi" , "marcin.nagy@aalto.fi" , "jo@comnet.tkk.fi" , "lars@netapp.com" Thread-Topic: Re : draft-singh-rmcat-adaptive-fec-00 Thread-Index: Ac+ZXmdio14geKr/T6CJ1qnvJDquvg== Date: Sun, 6 Jul 2014 21:54:02 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rrf66M5gg3evbCza9i1ht3jxuofF 4uvyblaL1Tc/sFnMOMHhwOpx/PViVo+zy6YyeSxZ8pPJY8anL2wBLFFcNimpOZllqUX6dglc GY9XpRU0uFUc2byAvYFxun0XIyeHhICJxPK2yewQtpjEhXvr2boYuTiEBI4ySvzd+ZwJwlnE KHHh5WMWkCo2ARuJlYe+M4IkRATWMUpM2tTGBpJgFsiSuLvpJiOILSygL9G+fg8riC0CtOLG 1UWMELaexM81M8DWsQioSEw43Q5WwyvgK3H15wKwGkYBWYn73++xQMwUl7j1ZD4TxHkCEkv2 nGeGsEUlXj7+xwphK0ms2H6JEaI+X+LNhEYmiJmCEidnPmGZwCg8C8moWUjKZiEpg4jrSdyY OoUNwtaWWLbwNTOErSsx498hFmTxBYzsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI+7g lt+qOxgvv3E8xCjAwajEw5tQuiNYiDWxrLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUw2jaWNgde2xB1fZvQ8ayN3FzfluysZt2hp/qiTGnfT1P9E+fbHn15pu7K asXtXSAZYZB4YobLi4S4qg7vSRdi06Zeu25d/ftIf+yuteZeZ29P1d35TU7IPn6+UMmszANL niSHrZ/4mY1XOoYxeImG+J9Vp0JF0u6Kqm3MnLqxPUm7/rRiksE3JZbijERDLeai4kQADIyn O5kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/VCIHX8iXcgMLhRnkC1GHm4T04rg Cc: Ingemar Johansson S , "rmcat WG \(rmcat@ietf.org\)" Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 21:54:10 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi A few comments to section 3.4 and on how I believe FEC can work with SCReAM= . First of all it would be necessary to add also the payload type info in the= feedback messages, this to be able to distinguish between ACK of the norma= l RTP packets and ACK of the FEC RTP packets. This should make it possible = to properly determine the number of bytes in flight and keep the ACK clocki= ng running. A second requirement is that the feedback reports must report t= he sequence numbers of received RTP (i.e before FEC has done its magic) On the sender side the FEC RTP packets are added to the send buffer just li= ke the normal RTP packets. Once this is in place the detailed packet loss info in SCReAM will help the= adaptive FEC framework to select the appropriate level of FEC. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "The difference between stupidity and genius is that genius has its limits." Albert Einstein =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

A few comments to section 3.4 and on how I believe F= EC can work with SCReAM.

 

First of all it would be necessary to add also the p= ayload type info in the feedback messages, this to be able to distinguish b= etween ACK of the normal RTP packets and ACK of the FEC RTP packets. This s= hould make it possible to properly determine the number of bytes in flight and keep the ACK clocking running.= A second requirement is that the feedback reports must report the sequence= numbers of received RTP (i.e before FEC has done its magic)

 

On the sender side the FEC RTP packets are added to = the send buffer just like the normal RTP packets.

 

Once this is in place the detailed packet loss info = in SCReAM will help the adaptive FEC framework to select the appropriate le= vel of FEC.

 

/Ingemar

 

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Senior Rese= archer

 =

Ericsson AB=

Wireless Ac= cess Networks

Labratorieg= r=E4nd 11

971 28, Lul= e=E5, Sweden

Phone += 46-1071 43042

SMS/MMS = 3;46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 =

“The difference betwe= en stupidity and

genius is that genius has its limits."
Albert Einstein
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3ESESSMB205erics_-- From nobody Sun Jul 6 23:27:45 2014 Return-Path: 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 9CF491A0347 for ; Sun, 6 Jul 2014 23:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 afobKvilCipQ for ; Sun, 6 Jul 2014 23:27:41 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976931A0B0D for ; Sun, 6 Jul 2014 23:27:40 -0700 (PDT) X-AuditID: c1b4fb3a-f799e6d000005085-61-53ba3dda18dc Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.5E.20613.ADD3AB35; Mon, 7 Jul 2014 08:27:38 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 08:27:37 +0200 From: Ingemar Johansson S To: Varun Singh Thread-Topic: Re : draft-singh-rmcat-adaptive-fec-00 Thread-Index: AQHPmWjAo14geKr/T6CJ1qnvJDquvpuUICuQ Date: Mon, 7 Jul 2014 06:27:37 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7E8A@ESESSMB205.ericsson.se> References: <20140706222227.B8D361E009@smtp.netlab.hut.fi> In-Reply-To: <20140706222227.B8D361E009@smtp.netlab.hut.fi> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7E8AESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvje4t213BBkdW6ll8Xd7NarH65gc2 iy9fXrA4MHscf72Y1WPJkp9MHos7zrMFMEdx2aSk5mSWpRbp2yVwZdy+sI2toKedsWLp3+ms DYx7mhm7GDk5JARMJJomTWaBsMUkLtxbz9bFyMUhJHCUUeLDtZvMEM4iRomv0z6DdbAJ2Eis PPQdzBYRUJXonn6TCcRmFgiTuH1xLzuILSxgLPH6wB9WiBoTiRtXF0HVG0m8eHoHrIZFQEXi w/J7YDavgK/E5O7FzCC2kICVxLWdh8FsTgFriXWbD7CB2IwCshL3v99jgdglLnHryXwmiKsF JJbsOc8MYYtKvHz8jxXCVpJoXPKEFaI+X2LWrT8sELsEJU7OfMIygVF0FpJRs5CUzUJSNouR AyiuKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgTG4cEtv612MB587niIUYCDUYmH98GxncFCrIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFxtfTPw1yVK1JFvmycY6R08oKE3WKmhrfdPtbvF8l9YW9cVX5N 9FLKsivbth1dwHFn/eENu2Zc+BrhKWFdotAY9s/3ikue1CLx6QuzZuSyskaxONluWepy57qI kvpTk2R5mZ4/XafU9IKLHy1vyLymNVlgYvMEM53Jhv3x3edZvu0M4JVxkS1QYinOSDTUYi4q TgQAunqhBaQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/9kF6LLbxkfQTOEnO8NSumqKvm7E Cc: "rmcat WG \(rmcat@ietf.org\)" , Nagy Marcin Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 06:27:43 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7E8AESESSMB205erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KQ29tbWVudHMgaW5saW5lDQoNClJlZ2FyZHMNCkluZ2VtYXINCg0KRnJvbTogVmFydW4g U2luZ2ggW21haWx0bzp2YXJ1bkBuZXRsYWIudGtrLmZpXQ0KU2VudDogZGVuIDcganVsaSAyMDE0 IDAwOjIyDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUw0KQ2M6IE5hZ3kgTWFyY2luOyBybWNhdCBX RyAocm1jYXRAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogUmUgOiBkcmFmdC1zaW5naC1ybWNhdC1h ZGFwdGl2ZS1mZWMtMDANCg0KDQpIaSBJbmdlbWFyLA0KDQpUaGFuayB5b3UgZm9yIHJlYWRpbmcg dGhlIHByb3Bvc2FsIGFuZCB0aGUgZmVlZGJhY2suIENvbW1lbnRzIGlubGluZS4NCg0KQ2hlZXJz LA0KVmFydW4uDQotLS0NCmh0dHA6Ly93d3cubmV0bGFiLnRray5maS9+dmFydW4NCk9uIDcgSnVs IDIwMTQgMDA6NTQsIEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KPg0KPiBIaQ0KPg0KPg0KPg0KPiBBIGZldyBjb21tZW50cyB0byBzZWN0aW9uIDMuNCBhbmQg b24gaG93IEkgYmVsaWV2ZSBGRUMgY2FuIHdvcmsgd2l0aCBTQ1JlQU0uDQo+DQo+DQo+DQo+IEZp cnN0IG9mIGFsbCBpdCB3b3VsZCBiZSBuZWNlc3NhcnkgdG8gYWRkIGFsc28gdGhlIHBheWxvYWQg dHlwZSBpbmZvIGluIHRoZSBmZWVkYmFjayBtZXNzYWdlcywgdGhpcyB0byBiZSBhYmxlIHRvIGRp c3Rpbmd1aXNoIGJldHdlZW4gQUNLIG9mIHRoZSBub3JtYWwgUlRQIHBhY2tldHMgYW5kIEFDSyBv ZiB0aGUgRkVDIFJUUCBwYWNrZXRzLiBUaGlzIHNob3VsZCBtYWtlIGl0IHBvc3NpYmxlIHRvIHBy b3Blcmx5IGRldGVybWluZSB0aGUgbnVtYmVyIG9mIGJ5dGVzIGluIGZsaWdodCBhbmQga2VlcCB0 aGUgQUNLIGNsb2NraW5nDQoNCkkgbmVlZCB0byBsb29rIGF0IHNjcmVhbSBwcm9wb3NhbCBpbiBh IGJpdCBtb3JlIGRldGFpbCB0byBzZWUgaWYgdGhlIGluY3JlYXNlIGluIHdpbmRvdyBhbmQgYWRk aXRpb24gb2YgRkVDIGNhbiBiZSBpbnRlcnR3aW5lZC4gQW55IHN1Z2dlc3Rpb25zIG9yIGZlZWRi YWNrIG9uIGhvdyBpdCBjb3VsZCB3b3JrPw0KDQpbSUpdIElmIG9uZSBsb29rIGF0IGZpZ3VyZSAz IGluIHlvdXIgZHJhZnQuIFRvIG1ha2UgaXQgd29yayB3aXRoIFNDUmVBTSBJIHdvdWxkIHB1dCB0 aGUgUlRQIHF1ZXVlIGJlbG93IHRoZSBGRUMgbW9kdWxlLiBUaGUgcmF0ZSBjb250cm9sIG1lYXN1 cmVzIHRoZSBxdWV1aW5nIGRlbGF5IGluIHRoZSBSVFAgcXVldWUuIElmIEZFQyBwYWNrZXRzIGFy ZSBpbnNlcnRlZCBpbnRvIHRoZSBxdWV1ZSBhbmQgdGhlIHRyYW5zbWlzc2lvbiBwYXRoIGlzIGNv bmdlc3RlZCB0aGVuIHRoZXJlIHdpbGwgYmUgbGVzcyByb29tIGZvciB0aGUgbm9ybWFsIFJUUCBw YWNrZXRzLCB0aGUgZWZmZWN0IGlzIHRoZW4gdGhhdCB0aGUgUlRQIHF1ZXVlIHdpbGwgYnVpbGQg dXAgd2l0aCB0aGUgY29uc2VxdWVuY2UgdGhhdCB0aGUgZW5jb2RlciBiaXRyYXRlIGlzIHJlZHVj ZWQuIFRodXMsIHRoZSBtb3JlIEZFQyB5b3UgYWRkLCB0aGUgbW9yZSB0aGUgYml0cmF0ZSBpcyBy ZWR1Y2VkIHRvIGZpdCBpbiB0aGUgYXZhaWxhYmxlIGNoYW5uZWwgY2FwYWNpdHkuLiBUaGlzIHBy b2JhYmx5IHJlcXVpcmVzIHNvbWUgZXhwZXJpbWVudGF0aW9uIHRvIHZlcmlmeSAoc2VlaW5nIGlz IGJlbGlldmluZy4uKQ0KDQo+IHJ1bm5pbmcuIEEgc2Vjb25kIHJlcXVpcmVtZW50IGlzIHRoYXQg dGhlIGZlZWRiYWNrIHJlcG9ydHMgbXVzdCByZXBvcnQgdGhlIHNlcXVlbmNlIG51bWJlcnMgb2Yg cmVjZWl2ZWQgUlRQIChpLmUgYmVmb3JlIEZFQyBoYXMgZG9uZSBpdHMgbWFnaWMpDQo+DQo+DQoN CkZvciByZXBvcnRzIHdlIGhhdmUgdXNlZCBydW4gbGVuZ3RoLWVuY29kZWQgKFJMRSkgcmVwb3J0 aW5nIG9mIGxvc3MgKHJmYzM2MTEpIGFuZCBkaXNjYXJkcyAoZHVlIHRvIGxhdGUgYXJyaXZhbCwg cmZjNzA5NykuIFRoZXNlIGdpdmVzIHRoZSBwYXR0ZXJuIG9mIGxvc3NlcyBhbmQgZGlzY2FyZHMs IGFkZGl0aW9uYWxseSB0aGVyZSBpcyB0aGUgcG9zdC1sb3NzIHJlcGFpci4gQ29tYmluaW5nIHRo ZXNlIHJlcG9ydHMgY2FuIGdldCB0aGF0IGluZm9ybWF0aW9uLiBUaGVzZSB0eXBpY2FsbHkgcmVw b3J0IG92ZXIgYmVnaW5fc2VxIGFuZCBlbmRfc2VxLCB3aGljaCBjYW4gYmUgc2luY2UgdGhlIGxh c3QgUlIuDQoNCklmIG92ZXJoZWFkIGlzIGFuIGlzc3VlLCB0aGVyZSBhcmUgY29ycmVzcG9uZGlu ZyBYUiBibG9ja3MgdGhhdCByZXBvcnQgY291bnRzIG9mIHBhY2tldHMgbG9zdC9kaXNjYXJkZWQv cG9zdC1yZXBhaXIgIGluIGFuIGludGVydmFsIHRoYXQgY2FuIGJlIHVzZWQgaW5zdGVhZCBvZiB0 aGUgUkxFIHJlcG9ydHMsIHdoaWNoIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlLg0KDQpbSUpdIFll cywgaXQgaXMgYW4gb3B0aW9uIHRvIHVzZSBSRkMzNjExIGFsc28gaW4gU0NSZUFNLCBJIHNraXBw ZWQgaXQgZm9yIGEgbW9yZSBzaW1wbGUgMzJiaXQgdmVjdG9yIGxvc3MgdmVjdG9yIGhvd2V2ZXIu DQoNCj4NCj4gT24gdGhlIHNlbmRlciBzaWRlIHRoZSBGRUMgUlRQIHBhY2tldHMgYXJlIGFkZGVk IHRvIHRoZSBzZW5kIGJ1ZmZlciBqdXN0IGxpa2UgdGhlIG5vcm1hbCBSVFAgcGFja2V0cy4NCj4N Cg0KSW4gb3VyIGltcGxlbWVudGF0aW9uLCB3ZSBpbnNlcnRlZCB0aGVtIGluIHRoZSBpbnRlcnZh bCBiZXR3ZWVuIHR3byB2aWRlbyBmcmFtZXMuIFRoZSBwYWNpbmcgYnVmZmVyIGNvdWxkIHNoYXBl IGl0IGZ1cnRoZXIuIEhvd2V2ZXIgZHJvcHBpbmcgRkVDIGZyb20gdGhlIHNlbmQgYnVmZmVyIG1h eSBwcm9iYWJseSByZXF1aXJlIHNvbWUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgRkVDIG1vZHVsZSAo Zm9yIGJvb2sga2VlcGluZyBhbmQgY2hhbmdpbmcgdGhlIGludGVybmFsIHN0YXRlKS4NCg0KW0lK XSBTb3VuZHMgcmVhc29uYWJsZSBhbmQgc2hvdWxkIGJlIGRvYWJsZSB3aXRoIFNDUmVBTSwgaGF2 ZSBub3QgdGhvdWdoIGFib3V0IHRoaXMgdG9vIG11Y2ggdGhvdWdoIGJ1dCBpdCBzaG91bGQgYmUg ZmFpcmx5IGVhc3kgdG8ganVzdCBhZGQgRkVDIGZyYW1lcywgdGhlIGJ1aWx0IGluIHJhdGUgY29u dHJvbCB3aWxsIHRoZW4gYWRqdXN0IHRoZSBlbmNvZGVyIGJpdHJhdGUgZGVwZW5kaW5nIG9uIHRo ZSBhbW91bnQgb2YgRkVDLg0KDQo+DQo+DQo+IE9uY2UgdGhpcyBpcyBpbiBwbGFjZSB0aGUgZGV0 YWlsZWQgcGFja2V0IGxvc3MgaW5mbyBpbiBTQ1JlQU0gd2lsbCBoZWxwIHRoZSBhZGFwdGl2ZSBG RUMgZnJhbWV3b3JrIHRvIHNlbGVjdCB0aGUgYXBwcm9wcmlhdGUgbGV2ZWwgb2YgRkVDLg0KPg0K Pg0KPg0KPiAvSW5nZW1hcg0KPg0KPg0KPg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4NCj4gSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQo+DQo+IFNlbmlvciBSZXNlYXJj aGVyDQo+DQo+DQo+DQo+IEVyaWNzc29uIEFCDQo+DQo+IFdpcmVsZXNzIEFjY2VzcyBOZXR3b3Jr cw0KPg0KPiBMYWJyYXRvcmllZ3LDpG5kIDExDQo+DQo+IDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4N Cj4NCj4gUGhvbmUgKzQ2LTEwNzEgNDMwNDINCj4NCj4gU01TL01NUyArNDYtNzMgMDc4IDMyODkN Cj4NCj4gaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tPg0KPg0KPiB3d3cuZXJpY3Nzb24uY29tPGh0dHA6Ly93d3cu ZXJpY3Nzb24uY29tPg0KPg0KPg0KPg0KPiDigJxUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0dXBp ZGl0eSBhbmQNCj4NCj4gZ2VuaXVzIGlzIHRoYXQgZ2VuaXVzIGhhcyBpdHMgbGltaXRzLiINCj4g QWxiZXJ0IEVpbnN0ZWluDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0K Pg0KPg0KPg0K --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7E8AESESSMB205erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHMgaW5saW5lPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZ2VtYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmFydW4gU2luZ2ggW21haWx0bzp2YXJ1bkBuZXRsYWIu dGtrLmZpXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRlbiA3IGp1bGkgMjAxNCAwMDoyMjxicj4NCjxi PlRvOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUzxicj4NCjxiPkNjOjwvYj4gTmFneSBNYXJjaW47 IHJtY2F0IFdHIChybWNhdEBpZXRmLm9yZyk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJlIDog ZHJhZnQtc2luZ2gtcm1jYXQtYWRhcHRpdmUtZmVjLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHA+SGkgSW5nZW1hciw8bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rIHlvdSBmb3IgcmVhZGlu ZyB0aGUgcHJvcG9zYWwgYW5kIHRoZSBmZWVkYmFjay4gQ29tbWVudHMgaW5saW5lLiA8bzpwPjwv bzpwPjwvcD4NCjxwPkNoZWVycyw8YnI+DQpWYXJ1bi48YnI+DQotLS08YnI+DQo8YSBocmVmPSJo dHRwOi8vd3d3Lm5ldGxhYi50a2suZmkvfnZhcnVuIj5odHRwOi8vd3d3Lm5ldGxhYi50a2suZmkv fnZhcnVuPC9hPjxicj4NCk9uIDcgSnVsIDIwMTQgMDA6NTQsIEluZ2VtYXIgSm9oYW5zc29uIFMg Jmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBIaTxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7 IEEgZmV3IGNvbW1lbnRzIHRvIHNlY3Rpb24gMy40IGFuZCBvbiBob3cgSSBiZWxpZXZlIEZFQyBj YW4gd29yayB3aXRoIFNDUmVBTS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBGaXJzdCBvZiBhbGwgaXQgd291bGQgYmUgbmVjZXNzYXJ5IHRvIGFkZCBhbHNv IHRoZSBwYXlsb2FkIHR5cGUgaW5mbyBpbiB0aGUgZmVlZGJhY2sgbWVzc2FnZXMsIHRoaXMgdG8g YmUgYWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIEFDSyBvZiB0aGUgbm9ybWFsIFJUUCBwYWNr ZXRzIGFuZCBBQ0sgb2YgdGhlIEZFQyBSVFAgcGFja2V0cy4gVGhpcyBzaG91bGQgbWFrZSBpdCBw b3NzaWJsZSB0byBwcm9wZXJseSBkZXRlcm1pbmUgdGhlIG51bWJlcg0KIG9mIGJ5dGVzIGluIGZs aWdodCBhbmQga2VlcCB0aGUgQUNLIGNsb2NraW5nPG86cD48L286cD48L3A+DQo8cD5JIG5lZWQg dG8gbG9vayBhdCBzY3JlYW0gcHJvcG9zYWwgaW4gYSBiaXQgbW9yZSBkZXRhaWwgdG8gc2VlIGlm IHRoZSBpbmNyZWFzZSBpbiB3aW5kb3cgYW5kIGFkZGl0aW9uIG9mIEZFQyBjYW4gYmUgaW50ZXJ0 d2luZWQuIEFueSBzdWdnZXN0aW9ucyBvciBmZWVkYmFjayBvbiBob3cgaXQgY291bGQgd29yaz88 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bSUpdIElmIG9uZSBsb29rIGF0IGZpZ3VyZSAzIGluIHlvdXIgZHJhZnQuIFRvIG1ha2Ug aXQgd29yayB3aXRoIFNDUmVBTSBJIHdvdWxkIHB1dCB0aGUgUlRQIHF1ZXVlIGJlbG93IHRoZSBG RUMgbW9kdWxlLiBUaGUgcmF0ZSBjb250cm9sIG1lYXN1cmVzIHRoZSBxdWV1aW5nIGRlbGF5IGlu IHRoZSBSVFANCiBxdWV1ZS4gSWYgRkVDIHBhY2tldHMgYXJlIGluc2VydGVkIGludG8gdGhlIHF1 ZXVlIGFuZCB0aGUgdHJhbnNtaXNzaW9uIHBhdGggaXMgY29uZ2VzdGVkIHRoZW4gdGhlcmUgd2ls bCBiZSBsZXNzIHJvb20gZm9yIHRoZSBub3JtYWwgUlRQIHBhY2tldHMsIHRoZSBlZmZlY3QgaXMg dGhlbiB0aGF0IHRoZSBSVFAgcXVldWUgd2lsbCBidWlsZCB1cCB3aXRoIHRoZSBjb25zZXF1ZW5j ZSB0aGF0IHRoZSBlbmNvZGVyIGJpdHJhdGUgaXMgcmVkdWNlZC4NCiBUaHVzLCB0aGUgbW9yZSBG RUMgeW91IGFkZCwgdGhlIG1vcmUgdGhlIGJpdHJhdGUgaXMgcmVkdWNlZCB0byBmaXQgaW4gdGhl IGF2YWlsYWJsZSBjaGFubmVsIGNhcGFjaXR5Li4gVGhpcyBwcm9iYWJseSByZXF1aXJlcyBzb21l IGV4cGVyaW1lbnRhdGlvbiB0byB2ZXJpZnkgKHNlZWluZyBpcyBiZWxpZXZpbmcuLik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IHJ1bm5pbmcuIEEgc2Vjb25kIHJlcXVpcmVtZW50IGlz IHRoYXQgdGhlIGZlZWRiYWNrIHJlcG9ydHMgbXVzdCByZXBvcnQgdGhlIHNlcXVlbmNlIG51bWJl cnMgb2YgcmVjZWl2ZWQgUlRQIChpLmUgYmVmb3JlIEZFQyBoYXMgZG9uZSBpdHMgbWFnaWMpPGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8cD5Gb3IgcmVwb3J0cyB3 ZSBoYXZlIHVzZWQgcnVuIGxlbmd0aC1lbmNvZGVkIChSTEUpIHJlcG9ydGluZyBvZiBsb3NzIChy ZmMzNjExKSBhbmQgZGlzY2FyZHMgKGR1ZSB0byBsYXRlIGFycml2YWwsIHJmYzcwOTcpLiBUaGVz ZSBnaXZlcyB0aGUgcGF0dGVybiBvZiBsb3NzZXMgYW5kIGRpc2NhcmRzLCBhZGRpdGlvbmFsbHkg dGhlcmUgaXMgdGhlIHBvc3QtbG9zcyByZXBhaXIuIENvbWJpbmluZyB0aGVzZSByZXBvcnRzIGNh biBnZXQgdGhhdCBpbmZvcm1hdGlvbi4NCiBUaGVzZSB0eXBpY2FsbHkgcmVwb3J0IG92ZXIgYmVn aW5fc2VxIGFuZCBlbmRfc2VxLCB3aGljaCBjYW4gYmUgc2luY2UgdGhlIGxhc3QgUlIuDQo8bzpw PjwvbzpwPjwvcD4NCjxwPklmIG92ZXJoZWFkIGlzIGFuIGlzc3VlLCB0aGVyZSBhcmUgY29ycmVz cG9uZGluZyBYUiBibG9ja3MgdGhhdCByZXBvcnQgY291bnRzIG9mIHBhY2tldHMgbG9zdC9kaXNj YXJkZWQvcG9zdC1yZXBhaXImbmJzcDsgaW4gYW4gaW50ZXJ2YWwgdGhhdCBjYW4gYmUgdXNlZCBp bnN0ZWFkIG9mIHRoZSBSTEUgcmVwb3J0cywgd2hpY2ggbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUu DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bSUpdIFllcywgaXQgaXMgYW4gb3B0aW9uIHRvIHVzZSBSRkMzNjExIGFsc28gaW4g U0NSZUFNLCBJIHNraXBwZWQgaXQgZm9yIGEgbW9yZSBzaW1wbGUgMzJiaXQgdmVjdG9yIGxvc3Mg dmVjdG9yIGhvd2V2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0Ozxicj4NCiZndDsg T24gdGhlIHNlbmRlciBzaWRlIHRoZSBGRUMgUlRQIHBhY2tldHMgYXJlIGFkZGVkIHRvIHRoZSBz ZW5kIGJ1ZmZlciBqdXN0IGxpa2UgdGhlIG5vcm1hbCBSVFAgcGFja2V0cy48YnI+DQomZ3Q7PG86 cD48L286cD48L3A+DQo8cD5JbiBvdXIgaW1wbGVtZW50YXRpb24sIHdlIGluc2VydGVkIHRoZW0g aW4gdGhlIGludGVydmFsIGJldHdlZW4gdHdvIHZpZGVvIGZyYW1lcy4gVGhlIHBhY2luZyBidWZm ZXIgY291bGQgc2hhcGUgaXQgZnVydGhlci4gSG93ZXZlciBkcm9wcGluZyBGRUMgZnJvbSB0aGUg c2VuZCBidWZmZXIgbWF5IHByb2JhYmx5IHJlcXVpcmUgc29tZSBpbnRlcmFjdGlvbiB3aXRoIHRo ZSBGRUMgbW9kdWxlIChmb3IgYm9vayBrZWVwaW5nIGFuZCBjaGFuZ2luZw0KIHRoZSBpbnRlcm5h bCBzdGF0ZSkuPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W0lKXSBTb3VuZHMgcmVhc29uYWJsZSBhbmQgc2hvdWxkIGJlIGRvYWJs ZSB3aXRoIFNDUmVBTSwgaGF2ZSBub3QgdGhvdWdoIGFib3V0IHRoaXMgdG9vIG11Y2ggdGhvdWdo IGJ1dCBpdCBzaG91bGQgYmUgZmFpcmx5IGVhc3kgdG8ganVzdCBhZGQgRkVDIGZyYW1lcywgdGhl IGJ1aWx0IGluIHJhdGUgY29udHJvbA0KIHdpbGwgdGhlbiBhZGp1c3QgdGhlIGVuY29kZXIgYml0 cmF0ZSBkZXBlbmRpbmcgb24gdGhlIGFtb3VudCBvZiBGRUMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmNlIHRoaXMgaXMgaW4gcGxh Y2UgdGhlIGRldGFpbGVkIHBhY2tldCBsb3NzIGluZm8gaW4gU0NSZUFNIHdpbGwgaGVscCB0aGUg YWRhcHRpdmUgRkVDIGZyYW1ld29yayB0byBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIGxldmVsIG9m IEZFQy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvSW5n ZW1hcjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7ID09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDs8YnI+DQomZ3Q7IEluZ2VtYXIg Sm9oYW5zc29uJm5ic3A7IE0uU2MuPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VuaW9yIFJlc2VhcmNo ZXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBFcmljc3Nv biBBQjxicj4NCiZndDs8YnI+DQomZ3Q7IFdpcmVsZXNzIEFjY2VzcyBOZXR3b3Jrczxicj4NCiZn dDs8YnI+DQomZ3Q7IExhYnJhdG9yaWVncsOkbmQgMTE8YnI+DQomZ3Q7PGJyPg0KJmd0OyA5NzEg MjgsIEx1bGXDpSwgU3dlZGVuPGJyPg0KJmd0Ozxicj4NCiZndDsgUGhvbmUgJiM0Mzs0Ni0xMDcx IDQzMDQyPGJyPg0KJmd0Ozxicj4NCiZndDsgU01TL01NUyAmIzQzOzQ2LTczIDA3OCAzMjg5PGJy Pg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT48YnI+DQomZ3Q7 PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbSI+d3d3LmVyaWNzc29u LmNvbTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDi gJxUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0dXBpZGl0eSBhbmQ8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBnZW5pdXMgaXMgdGhhdCBnZW5pdXMgaGFzIGl0cyBsaW1pdHMuJnF1b3Q7PGJyPg0KJmd0OyBB bGJlcnQgRWluc3RlaW48YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FA7E8AESESSMB205erics_-- From nobody Mon Jul 7 01:26:48 2014 Return-Path: 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 0582D1B27C8 for ; Mon, 7 Jul 2014 01:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 LKCLol85nv6l for ; Mon, 7 Jul 2014 01:26:45 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642621B27C5 for ; Mon, 7 Jul 2014 01:26:45 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so6395634wiv.2 for ; Mon, 07 Jul 2014 01:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=pEupQ3ZuwcqLp3qzhaGY752z+NBhFUsrAdogpj2ICEQ=; b=yM/dPkNklo/cSI1EEP+bbeDs5rlCKkVjpLcU1x05zhTL7qfhbaemrEOIwSINccRwdm xRzAzp7GY1Wbl9H+i8chpBN5/JJsXbNysMg2sJiPSsxLgnEBLzhwTO8YYngrcMv8BuIs FrM0EVCXSLnmm5Xcv78WM5GpUhBAk00h4efDw1XdFjEued88UA5FShsRml+7uUMK8QBS FoDPsHWTR7hPf/5x5RzqLy8tiCWdyGA99Mg6mdkNGdf9YSu4L6+x1h5QBvDrtknnnFC9 xvheK9ACYlVx9ySg29kAHQmqX5sCNClJczEJ3OWloM1r89SvFmRi8OJmBEQh1FVso3Ap sDuA== X-Received: by 10.194.104.97 with SMTP id gd1mr29332450wjb.77.1404721603679; Mon, 07 Jul 2014 01:26:43 -0700 (PDT) Received: from [192.168.1.47] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id au7sm31112473wjc.41.2014.07.07.01.26.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 01:26:42 -0700 (PDT) Message-ID: <53BA59C6.8090802@gmail.com> Date: Mon, 07 Jul 2014 10:26:46 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3@ESESSMB205.ericsson.se> Content-Type: multipart/alternative; boundary="------------030006000300050806020502" Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/5_c2EnAHoAnwvWUOJSRqzxbEzls Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 08:26:47 -0000 This is a multi-part message in MIME format. --------------030006000300050806020502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/07/2014 23:54, Ingemar Johansson S wrote: > > Hi > > A few comments to section 3.4 and on how I believe FEC can work with > SCReAM. > > First of all it would be necessary to add also the payload type info > in the feedback messages, this to be able to distinguish between ACK > of the normal RTP packets and ACK of the FEC RTP packets. This should > make it possible to properly determine the number of bytes in flight > and keep the ACK clocking running. A second requirement is that the > feedback reports must report the sequence numbers of received RTP (i.e > before FEC has done its magic) > > On the sender side the FEC RTP packets are added to the send buffer > just like the normal RTP packets. > > Once this is in place the detailed packet loss info in SCReAM will > help the adaptive FEC framework to select the appropriate level of FEC. > > Hi Ingemar, Most probably I am missing something, but shouldn't the FEC and the primary stream be different RTP streams? that's it, each one should have their own ssrc value, so your requirements above should be fulfilled already. Best regards Sergio --------------030006000300050806020502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/07/2014 23:54, Ingemar Johansson S wrote:

Hi

 

A few comments to section 3.4 and on how I believe FEC can work with SCReAM.

 

First of all it would be necessary to add also the payload type info in the feedback messages, this to be able to distinguish between ACK of the normal RTP packets and ACK of the FEC RTP packets. This should make it possible to properly determine the number of bytes in flight and keep the ACK clocking running. A second requirement is that the feedback reports must report the sequence numbers of received RTP (i.e before FEC has done its magic)

 

On the sender side the FEC RTP packets are added to the send buffer just like the normal RTP packets.

 

Once this is in place the detailed packet loss info in SCReAM will help the adaptive FEC framework to select the appropriate level of FEC.

 

Hi Ingemar,

Most probably I am missing something, but shouldn't the FEC and the primary stream be different RTP streams? that's it, each one should have their own ssrc value, so your requirements above should be fulfilled already.

Best regards
Sergio
--------------030006000300050806020502-- From nobody Mon Jul 7 01:30:09 2014 Return-Path: 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 75A961A0349 for ; Mon, 7 Jul 2014 01:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 H6ecDAXQ4fP9 for ; Mon, 7 Jul 2014 01:30:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC781B27CF for ; Mon, 7 Jul 2014 01:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1415; q=dns/txt; s=iport; t=1404721808; x=1405931408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dibdd/FwVmrvn/IITPLMUyOk3kvV9S/eglVIgwMV0JE=; b=Wwx9p04O64RF9Vqk0hxU82n1e1pLAVUcbw/DgMzVfvGEww+cnvbCkjH4 sOXIukMHKeLKniV+O1+kE73eLixyKoLMqwuizuEH8TRp066VPfc8m6U5U iYo9HuN7/WSHk6KlagSpyZWA7G1lOVtPliVIQZ2BFo3YfMKMMMFsDOHzD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAKlZulOtJA2I/2dsb2JhbABagmokgSzGMgGBEBZ1hAMBAQEDAXkFCwIBCBguIRElAQEEDgWILgMJCAHDHQ2GMBeMeoF1MweDLYEWAQSKF45fggCNeIYUg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,616,1400025600"; d="scan'208";a="58754625" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 07 Jul 2014 08:30:07 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s678U6CL007813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 08:30:06 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 03:30:06 -0500 From: "Ali C. Begen (abegen)" To: Sergio Garcia Murillo Thread-Topic: [rmcat] draft-singh-rmcat-adaptive-fec-00 Thread-Index: Ac+ZXmdio14geKr/T6CJ1qnvJDquvgAiLIIAAAAdp4A= Date: Mon, 7 Jul 2014 08:30:05 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3@ESESSMB205.ericsson.se> <53BA59C6.8090802@gmail.com> In-Reply-To: <53BA59C6.8090802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.233.42] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3AC9B231411CB54FAA4EFC19F8EE4532@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/5Tf1qrI73_0__0D5o8pu34-sykY Cc: "rmcat@ietf.org" Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 08:30:08 -0000 On Jul 7, 2014, at 5:26 PM, Sergio Garcia Murillo wrote: > On 06/07/2014 23:54, Ingemar Johansson S wrote: >> Hi >> =20 >> A few comments to section 3.4 and on how I believe FEC can work with SCR= eAM. >> =20 >> First of all it would be necessary to add also the payload type info in = the feedback messages, this to be able to distinguish between ACK of the no= rmal RTP packets and ACK of the FEC RTP packets. This should make it possib= le to properly determine the number of bytes in flight and keep the ACK clo= cking running. A second requirement is that the feedback reports must repor= t the sequence numbers of received RTP (i.e before FEC has done its magic) >> =20 >> On the sender side the FEC RTP packets are added to the send buffer just= like the normal RTP packets. >> =20 >> Once this is in place the detailed packet loss info in SCReAM will help = the adaptive FEC framework to select the appropriate level of FEC. >> =20 > Hi Ingemar, >=20 > Most probably I am missing something, but shouldn't the FEC and the prima= ry stream be different RTP streams? that's it, each one should have their o= wn ssrc value, so your requirements above should be fulfilled already. Not all FEC schemes work that way but this is obviously the preferred (and = correct) way of doing FEC for RTP. See RFC 6363. >=20 > Best regards > Sergio From nobody Mon Jul 7 01:41:30 2014 Return-Path: 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 227801B27DE for ; Mon, 7 Jul 2014 01:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7QlNlRGAJh0H for ; Mon, 7 Jul 2014 01:41:27 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4761A00FD for ; Mon, 7 Jul 2014 01:41:27 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so2980866wgh.7 for ; Mon, 07 Jul 2014 01:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Dawiyr0P4GAnOMHlEQuzGM2delQpKDQZ4yDpHUSlPY4=; b=Y54BDD+AltYYCPgr4ubIjgvZFcBK7emmnf19OaT2UjyP+y1x9JMa8A2RL3CzF3lfMQ 6DHKXtGqw9VHeqSI1Y7YJ3FSNarku4/J0WB1SU4+7o1zjgUciorFanhZNyuZ3ro0SpdC LDNQMRiKkE8lb7Pam31ffy/LVRUuIR8Cc0nVKHq5ZI6zjxwgQwBYukxfbrNifDcarlFU x4HRtG0+NQ/LzcLnotXhJ6D9OAv2OCBfjPXvK2id5cK4N5cX6TUsS7txAgGte3cNrP/J 4tSpEPo6DxXYrdj2tOavpGZN1Z+XxPmYZicvDH/Fu6wtFNRFtlokZn7L0ZvHLFrvEs6o 39Hg== X-Received: by 10.194.90.106 with SMTP id bv10mr31387622wjb.20.1404722486200; Mon, 07 Jul 2014 01:41:26 -0700 (PDT) Received: from [192.168.1.47] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id fb15sm112628751wid.23.2014.07.07.01.41.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 01:41:25 -0700 (PDT) Message-ID: <53BA5D39.9070704@gmail.com> Date: Mon, 07 Jul 2014 10:41:29 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3@ESESSMB205.ericsson.se> <53BA59C6.8090802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/vp40P3U4_kcM68dA4voLgEfeo7g Cc: "rmcat@ietf.org" Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 08:41:29 -0000 On 07/07/2014 10:30, Ali C. Begen (abegen) wrote: > On Jul 7, 2014, at 5:26 PM, Sergio Garcia Murillo wrote: > >> On 06/07/2014 23:54, Ingemar Johansson S wrote: >>> Hi >>> >>> A few comments to section 3.4 and on how I believe FEC can work with SCReAM. >>> >>> First of all it would be necessary to add also the payload type info in the feedback messages, this to be able to distinguish between ACK of the normal RTP packets and ACK of the FEC RTP packets. This should make it possible to properly determine the number of bytes in flight and keep the ACK clocking running. A second requirement is that the feedback reports must report the sequence numbers of received RTP (i.e before FEC has done its magic) >>> >>> On the sender side the FEC RTP packets are added to the send buffer just like the normal RTP packets. >>> >>> Once this is in place the detailed packet loss info in SCReAM will help the adaptive FEC framework to select the appropriate level of FEC. >>> >> Hi Ingemar, >> >> Most probably I am missing something, but shouldn't the FEC and the primary stream be different RTP streams? that's it, each one should have their own ssrc value, so your requirements above should be fulfilled already. > Not all FEC schemes work that way but this is obviously the preferred (and correct) way of doing FEC for RTP. See RFC 6363. > Sure! I was expecting doing FEC in the correct way!! ;) Shouldn't we add that to the draft? Best regards Sergio From nobody Mon Jul 7 12:26:03 2014 Return-Path: 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 BD27E1B286D for ; Mon, 7 Jul 2014 12:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qpQ-0cH4bMkD for ; Mon, 7 Jul 2014 12:26:01 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E881A0357 for ; Mon, 7 Jul 2014 12:26:00 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-1b-53baf4464174 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.2C.19155.644FAB35; Mon, 7 Jul 2014 21:25:58 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 21:25:57 +0200 From: Ingemar Johansson S To: Sergio Garcia Murillo , "Ali C. Begen (abegen)" Thread-Topic: [rmcat] draft-singh-rmcat-adaptive-fec-00 Thread-Index: AQHPmhlGvlzVlIZ1b0aPJ+DsN3jeog== Date: Mon, 7 Jul 2014 19:25:56 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA8CBF@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31FA7DD3@ESESSMB205.ericsson.se> <53BA59C6.8090802@gmail.com> <53BA5D39.9070704@gmail.com> In-Reply-To: <53BA5D39.9070704@gmail.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja7bl13BBlMPi1g82D6X0WL1zQ9s Fk//bWd2YPaY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlbHmxBO2gqkCFV92H2Zq YLzB08XIwSEhYCLRPbeii5ETyBSTuHBvPRuILSRwlFHizQJbCHsRo8T1w/EgNpuAjcTKQ98Z QWwRgUyJj1P2sYDYzAKqEhOeTwDrFRYwk3j96i4bRI25xO1LJ6BsPYn3e7tZQWwWARWJlz+2 gfXyCvhKrGh6ClTDBbRrD6PEoZWTmUFu4xTQlFgypwSkhlFAVuL+93tQu8Qlbj2ZzwRxs4DE kj3nmSFsUYmXj/+xQthKEmsPb4eq15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg2C8nYWUha ZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwHg6uOW36g7Gy28cDzEKcDAq 8fAqPNgVLMSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMsm XN8/oXaPfeuXG47ndP5Xv5aX79Y8rLhml7SVW9D1GdERv8NP6N1JnFadkfrkat2OI3r3Zvw9 mCD6SflqD/v70oy1ZfbKPrI7bKfESXgVT/YzfOHBEtyn5tjabSLxP0u6sH+Lr0GdgFanLr+B m0ejzK4M1Y5ltTF1vI4bTW/EGUUzfk1TYinOSDTUYi4qTgQA5yKinogCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/zTFj72BwLn_E-1Lnato1kSe79mg Cc: "rmcat@ietf.org" Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:26:02 -0000 Hi=20 Thanks for the clarificaion, this of course simplifies things even though i= t is not overly complex to add PT in the feedback, just a little more overh= ead. /Ingemar=20 > -----Original Message----- > From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] > Sent: den 7 juli 2014 10:41 > To: Ali C. Begen (abegen) > Cc: rmcat@ietf.org > Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00 >=20 > On 07/07/2014 10:30, Ali C. Begen (abegen) wrote: > > On Jul 7, 2014, at 5:26 PM, Sergio Garcia Murillo > wrote: > > > >> On 06/07/2014 23:54, Ingemar Johansson S wrote: > >>> Hi > >>> > >>> A few comments to section 3.4 and on how I believe FEC can work with > SCReAM. > >>> > >>> First of all it would be necessary to add also the payload type info = in the > feedback messages, this to be able to distinguish between ACK of the norm= al > RTP packets and ACK of the FEC RTP packets. This should make it possible = to > properly determine the number of bytes in flight and keep the ACK clockin= g > running. A second requirement is that the feedback reports must report th= e > sequence numbers of received RTP (i.e before FEC has done its magic) > >>> > >>> On the sender side the FEC RTP packets are added to the send buffer > just like the normal RTP packets. > >>> > >>> Once this is in place the detailed packet loss info in SCReAM will he= lp the > adaptive FEC framework to select the appropriate level of FEC. > >>> > >> Hi Ingemar, > >> > >> Most probably I am missing something, but shouldn't the FEC and the > primary stream be different RTP streams? that's it, each one should have > their own ssrc value, so your requirements above should be fulfilled alre= ady. > > Not all FEC schemes work that way but this is obviously the preferred (= and > correct) way of doing FEC for RTP. See RFC 6363. > > > Sure! I was expecting doing FEC in the correct way!! ;) >=20 > Shouldn't we add that to the draft? >=20 > Best regards > Sergio >=20 From nobody Sun Jul 13 07:18:30 2014 Return-Path: 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 EC0141B2876 for ; Sun, 13 Jul 2014 07:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no 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 zpST4Eezwoin for ; Sun, 13 Jul 2014 07:18:27 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1031B282E for ; Sun, 13 Jul 2014 07:18:25 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so3025058wes.41 for ; Sun, 13 Jul 2014 07:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=XcPOsHl+8IJg+aQkfBmKjD7GzWXX4CyjI7jtfIfuS04=; b=VYz+EqCy6Fy6207wDuM9uup/bzCp6QskPFWvC8jPBe8E04ViIhaOYPsJkd4PUih8Qu pmPX9j7UfEMqe0ZpmJU0lEitit8iSQ/MCC0DlOaxLrkvpQTJ2kX5XL2SdiQwhxIs4xTT sbrIlKzcrEDT0PIPwuaAUlH1rJJqGAIf73DnA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=XcPOsHl+8IJg+aQkfBmKjD7GzWXX4CyjI7jtfIfuS04=; b=YNBFGCc8sHRAx/TyA+3tL5Vxj7qq4uyS38YSfjgtDuY6N8NGtKSjXoChrIg3EUo6UB Xlo1csxqOlfDlv/yXthXHrzLaHcSTxBnVanBTrsdnxEZ9USY6vHyi61arajyoVXtnaJ8 Tz/UNDiPERn1FzUdHJQ176srag1XtJCL7pP44WRxU4NX8Z2RTO90Ss+M2B92Wmn1UZqR 68wFNRmbRo8CP8ltRPCktB2/VnGhLzKMlvbUEguk9MK3QsW3omEoG7s88Hiugk1zKfvy SS15s9J0JgQsnwmhUf59Jn0xuSUXoENS9lyrbXejFUR6Fz4/HFFqRdiSJaoFUn+ia4xi 3j0g== X-Gm-Message-State: ALoCoQm+bVJuO/7zNp04bhFW1B7+i+5tln2vwRXFzJe/+MNzVbz3lgcYyFrRIreR2lvYbC4WTGt5hOqMTwk4fQB7Q+Zgta4pHQ== X-Received: by 10.180.89.233 with SMTP id br9mr17935436wib.14.1405261103800; Sun, 13 Jul 2014 07:18:23 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIC0GcS6o0gWd4sSRQD+GJFinDLiQD8LeuJmy/HP5A= Date: Sun, 13 Jul 2014 16:18:23 +0200 Message-ID: To: Varun Singh , rmcat WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/LJ4BEJZ_Z5KMbSwoWSEpz2hjbCI Cc: =?UTF-8?B?SsO2cmcgT3R0?= , "Eggert, Lars" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [rmcat] Please review draft-ietf-rmcat-eval-criteria-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 14:18:29 -0000 Hi Varun, The draft also references the Jain-fairness index (Open Issues 2) how does this relate to open issue 1 (below). Editorial - I think ? - In Section 3 you start by using a bulleted format but then after item 5., the bullet format is no longer used. Is that intentionally ? Thanks. BR, Karen > -----Original Message----- > From: Varun Singh [mailto:vsingh.ietf@gmail.com] > Sent: 12. juni 2014 13:28 > To: rmcat WG > Cc: Eggert, Lars; Karen E. Egede Nielsen; J=C3=B6rg Ott; Mirja K=C3=BChle= wind > Subject: Re: Please review draft-ietf-rmcat-eval-criteria-01 > > Hi all, > > There was one one open issue that needs to be discussed and it is related > to > fairness :) > > This has been discussed at length in the design group meetings and also a= t > the IETF meetings, but I am not sure if the text in the open issue had > working > group agreement. > > The summary of the discussion so far is: > - The eval-criteria needs to define a guideline that helps in evaluating > an > RMCAT proposal > - The individual test case should define its expected fairness criteria, > and it > may vary between scenarios. > > NEW TEXT to replace the open issue: > > Fairness or Unfairness: Experiments testing the performance of an > RMCAT proposal against any cross-traffic must define its expected > criteria for fairness. > > The "unfairness" test guideline to assist in defining such a criteria > (measured at 1s intervals) is: > 1. Does not trigger the circuit breaker. > 2. When the competing streams with identical RMCAT streams having > similar RTTs, > no stream achieves over 3 times the min RMCAT stream or less than > 1/3 times the > throughput of the max RMCAT stream. > 3. When competing with identical RMCAT streams having similar RTTs, > no RTT measurements for an RMCAT stream is over 3 times delay compared > to RTT > measurements performed before starting the RMCAT flow. > > > Next step: > Is the guideline helpful and should be in the draft?, or suggestion, and > counter proposals are welcome. > > Cheers, > Varun > > > On Mon, Mar 31, 2014 at 5:02 PM, Mirja K=C3=BChlewind > wrote: > > Hi group, > > > > draft-ietf-rmcat-eval-criteria-01 was updated after the last meeting > > addressing all comments from the meeting. We would really need people > > to review this document now! Please do so! > > > > https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ > > > > Mirja > > > > > > > > -- > http://www.netlab.tkk.fi/~varun/ From nobody Mon Jul 14 07:38:18 2014 Return-Path: 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 1B3511A05CB for ; Mon, 14 Jul 2014 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 mM9UiYplz8xx for ; Mon, 14 Jul 2014 07:38:15 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EB61A0537 for ; Mon, 14 Jul 2014 07:38:15 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so1790574iga.7 for ; Mon, 14 Jul 2014 07:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5DY8OkrvmRtu933arvfmGAdtPuIV+pyNQNE2xGkAApc=; b=swBN9CLVsxwzd76Wssb3jLz6I8s/KwVNOKn8GYwaJY3TQBCvdbGrBPrbyQr7GMBY0r o5eKT0W0kNm1bAx8QxZR08gpeue+Zslf4ALsNM2ZAI3obOhPtJ4/Tkdov/mRn9di/l0O ZGgywUDujgSLvjIP3a4BQfz/IMDqxu01ExvyLtoSjPYFW4Asg9iCSmT23B/+7q3JNlw0 hc8xfR87K/Sos5tKrj4yoVQu26M9qWkr+mukpwJDaFu/ePROGEQ9uqBannX05P+RUHh2 Lz30p0kPbLxk2nuMMvY0abBsV8UsSJ3AIRckQ2W9uj86uk+6U6OleZeqsg50Si+1lm4y 7VYg== X-Received: by 10.42.139.4 with SMTP id e4mr3695774icu.73.1405348694864; Mon, 14 Jul 2014 07:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.119.38 with HTTP; Mon, 14 Jul 2014 07:37:54 -0700 (PDT) In-Reply-To: <8B1B16F2-3E29-4817-9B22-F76E9957AEFA@ifi.uio.no> References: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> <8B1B16F2-3E29-4817-9B22-F76E9957AEFA@ifi.uio.no> From: Varun Singh Date: Mon, 14 Jul 2014 17:37:54 +0300 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/TBoZ6cSRpQaG7ph_MyyvEkXSEYU Cc: rmcat WG Subject: Re: [rmcat] Please review draft-ietf-rmcat-eval-criteria-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 14:38:17 -0000 Hi Michael, Missed this email from earlier, comments inline. Cheers, Varun On Fri, Jun 13, 2014 at 4:07 PM, Michael Welzl wrote: > Hi, > > On 12. juni 2014, at 13:28, Varun Singh wrote: > >> Hi all, >> >> There was one one open issue that needs to be discussed and it is >> related to fairness :) >> >> This has been discussed at length in the design group meetings and >> also at the IETF meetings, but I am not sure if the text in the open >> issue had working group agreement. >> >> The summary of the discussion so far is: >> - The eval-criteria needs to define a guideline that helps in >> evaluating an RMCAT proposal >> - The individual test case should define its expected fairness >> criteria, and it may vary between scenarios. >> >> NEW TEXT to replace the open issue: >> >> Fairness or Unfairness: Experiments testing the performance of an >> RMCAT proposal against any cross-traffic must define its expected >> criteria for fairness. >> >> The "unfairness" test guideline to assist in defining such a >> criteria (measured at 1s intervals) is: >> 1. Does not trigger the circuit breaker. >> 2. When the competing streams with identical RMCAT streams having >> similar RTTs, >> no stream achieves over 3 times the min RMCAT stream or less than >> 1/3 times the >> throughput of the max RMCAT stream. > > In principle, what this new text up to here is trying to say (if I interp= ret it correctly) sounds good to me. > However, the English is pretty broken, please fix. > 2. When competing with identical RMCAT streams having similar RTTs, no RMCAT stream achieves more than 3 times the average throughput of the RMCAT stream with the lowest average throughput, or less than 1/3 times the average throughput of the RMCAT stream with the highest average throughput. > >> 3. When competing with identical RMCAT streams having similar RTTs, >> no RTT measurements for an RMCAT stream is over 3 times delay compared= to RTT >> measurements performed before starting the RMCAT flow. > > Huh? "Compared to measurements performed before starting the RMCAT flow" = =3D> which one? All, including the background flows, or only the foreground= flow? The foreground flow must not make the RTT grow by a factor of 3, is = that it? I think that's not a fairness criterion, it's a delay-minimizing c= riterion, and a weird one too. I wonder if this could just be removed. My interpretation of the proposal was that the RTT should not grow by a factor of 3 for the existing flows when a new flow is added. I can remove this, if there is consensus on removing this requirement. I do not remember correctly who made the original proposal (was perhaps Kevin Gross), but was in a design meeting from a year ago. > > Cheers, > Michael > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Mon Jul 14 07:46:51 2014 Return-Path: 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 2740B1A0652 for ; Mon, 14 Jul 2014 07:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4NP_c9GcOtFf for ; Mon, 14 Jul 2014 07:46:48 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9039F1A0649 for ; Mon, 14 Jul 2014 07:46:48 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so1282389iec.33 for ; Mon, 14 Jul 2014 07:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=LZozV4VKo2P4+9HRFQuRl/8Z0dIdxD679O/urSlGz0c=; b=gPFFOB3CI4GXiI0r6FrctJq9kGXqUg2D5uCABbcRAn0Oa0//N901HJK58qoHTW9XYc u1i0LH8PyX1uRHY7hr5Ggx0OJ/gmnWSzNhW1aKj25bbYGS/5Ho4Ax6h9OQe15jN6UGNk cnJ94o3Y5RR5DahEIfx/mlJOEFhxorjKIOsnqpTGUmJYCdHrR8jlG/oYDD/G4W+1E81E w+dGUZdDGC87Z/qZL4NMSg1ykhuUKWrouqMuQS+5u4hEdmfa6SuBPML6FabjpOCLXecD UMGjzUw8weLrJk0EDYfchViO6OiU7PSwakd+dwCm0QhmBiGQUZ72sR+Rd9O9QfAUmfjq 8HoQ== X-Received: by 10.42.12.76 with SMTP id x12mr3237982icx.96.1405349207860; Mon, 14 Jul 2014 07:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.119.38 with HTTP; Mon, 14 Jul 2014 07:46:27 -0700 (PDT) In-Reply-To: References: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> From: Varun Singh Date: Mon, 14 Jul 2014 17:46:27 +0300 Message-ID: To: "Karen E. Egede Nielsen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/so9Kwv61MGTE2w-fTkSocifjyLQ Cc: =?UTF-8?B?SsO2cmcgT3R0?= , rmcat WG , "Eggert, Lars" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [rmcat] Please review draft-ietf-rmcat-eval-criteria-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 14:46:50 -0000 Hi Karen, Thank you for the feedback, comments in line. - Varun. On Sun, Jul 13, 2014 at 5:18 PM, Karen E. Egede Nielsen wrote: > Hi Varun, > > The draft also references the Jain-fairness index (Open Issues 2) how doe= s > this relate to open issue 1 (below). > I think it is still TBD, the assumption last year was that we need more evaluation results before we can comment on the list of metrics. Since, there are more evaluations in the upcoming meeting, I believe we might be getting closer to answering the question. > Editorial - I think ? - In Section 3 you start by using a bulleted format > but then after item 5., the bullet format is no longer used. Is that > intentionally ? > These items were editor notes before, which may explain why they were outside the < list >. They should be bullet items. Will be fixed in the next version. > Thanks. > > BR, Karen > >> -----Original Message----- >> From: Varun Singh [mailto:vsingh.ietf@gmail.com] >> Sent: 12. juni 2014 13:28 >> To: rmcat WG >> Cc: Eggert, Lars; Karen E. Egede Nielsen; J=C3=B6rg Ott; Mirja K=C3=BChl= ewind >> Subject: Re: Please review draft-ietf-rmcat-eval-criteria-01 >> >> Hi all, >> >> There was one one open issue that needs to be discussed and it is relate= d >> to >> fairness :) >> >> This has been discussed at length in the design group meetings and also = at >> the IETF meetings, but I am not sure if the text in the open issue had >> working >> group agreement. >> >> The summary of the discussion so far is: >> - The eval-criteria needs to define a guideline that helps in evaluating >> an >> RMCAT proposal >> - The individual test case should define its expected fairness criteria, >> and it >> may vary between scenarios. >> >> NEW TEXT to replace the open issue: >> >> Fairness or Unfairness: Experiments testing the performance of an >> RMCAT proposal against any cross-traffic must define its expected >> criteria for fairness. >> >> The "unfairness" test guideline to assist in defining such a criteria >> (measured at 1s intervals) is: >> 1. Does not trigger the circuit breaker. >> 2. When the competing streams with identical RMCAT streams having >> similar RTTs, >> no stream achieves over 3 times the min RMCAT stream or less than >> 1/3 times the >> throughput of the max RMCAT stream. >> 3. When competing with identical RMCAT streams having similar RTTs, >> no RTT measurements for an RMCAT stream is over 3 times delay compare= d >> to RTT >> measurements performed before starting the RMCAT flow. >> >> >> Next step: >> Is the guideline helpful and should be in the draft?, or suggestion, and >> counter proposals are welcome. >> >> Cheers, >> Varun >> >> >> On Mon, Mar 31, 2014 at 5:02 PM, Mirja K=C3=BChlewind >> wrote: >> > Hi group, >> > >> > draft-ietf-rmcat-eval-criteria-01 was updated after the last meeting >> > addressing all comments from the meeting. We would really need people >> > to review this document now! Please do so! >> > >> > https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ >> > >> > Mirja >> > >> > >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ --=20 http://www.netlab.tkk.fi/~varun/ From nobody Mon Jul 14 08:01:46 2014 Return-Path: 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 4644D1A0648 for ; Mon, 14 Jul 2014 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no 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 REGB54Xc6KI0 for ; Mon, 14 Jul 2014 08:01:43 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587E01A0647 for ; Mon, 14 Jul 2014 08:01:43 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so1761397igb.15 for ; Mon, 14 Jul 2014 08:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TxOQQ3qtJ609VRErh2JPc1ayqmUtCfdQdp8nURMZqfg=; b=jBvoolYDvi5SwrxShklFo/ROVN3Gq8Q8cNesPGEKat/nqPoIaJiSm8WC+2snczw62x zBAg7XaqDmZiMVUUM7aQgIBa+p5AuPsy5PRZqAV20uW7BhE/vWKFg8l8yakNkjB2pon2 ktjhVnCN77wGOCo7J7U8og46Oa9qQf1xPdTtHY4qmXPbfeCoTZoj7O7wOS+CZg5fQo97 BknHQ6SsBYNa0p9nanosZWgy7wHQbX1PqC5iEKKKsRLQybnbLun3dqVHsZSQ0qfGh/JZ X8HqzdrSM7q2Kzkdg4ngIbGd10xRx3qqfidzRq81hOs9q1Ng7ejALWw33C+DjL7dzaXl xCTQ== X-Received: by 10.50.141.199 with SMTP id rq7mr26018757igb.37.1405350102754; Mon, 14 Jul 2014 08:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.119.38 with HTTP; Mon, 14 Jul 2014 08:01:22 -0700 (PDT) In-Reply-To: References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA31F9F56B@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA31FA50F7@ESESSMB205.ericsson.se> <53AC0DC9.2020803@ericsson.com> From: Varun Singh Date: Mon, 14 Jul 2014 18:01:22 +0300 Message-ID: To: Luca De Cicco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/wGVlGd_Yi65GFFgATTaIPLjZ4Is Cc: "rmcat WG \(rmcat@ietf.org\)" , Zaheduzzaman Sarker Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 15:01:45 -0000 Hi Luca, My implementation of GCC was based on: http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02 (spring/summer 2012) and earlier, which didn't yet contain the text relating to processing multiple streams from a single endpoint. This had me wondering for a moment on how to incorporate these streams into GCC. With the addition of the RTP to NTP time conversion, the GCC arrival filter can work across timestamps from repair, audio and video packets. Cheers, Varun On Thu, Jun 26, 2014 at 4:38 PM, Luca De Cicco wrote: > Dear Varun, > > the way RTX or FEC are computed shouldn't impact GCC sending rate dynamic= s, > but only > the user's QoE. > > Cheers, > Luca > > On Thu, Jun 26, 2014 at 3:11 PM, Varun Singh wrot= e: >> >> Hi Zahed, >> >> Does your GCC simulation code implement any FEC or Retx? Since the gcc >> draft does not imply use of any repair mechanism even though the chrome >> browser implements both. >> >> On 26 Jun 2014 14:11, "Zaheduzzaman Sarker" >> wrote: >>> >>> Hi Luca, >>> >>> The simulation code is implemented in our proprietary simulator (I shou= ld >>> thank my MS thesis workers who contributed a lot). Thus cant really sha= re >>> the code but what I can share is some simulation results. >>> >>> Note that in our implementation we followed latest update for varying >>> threshold from the GCC draft >>> >>> If you want GCC related logs particularly for LTE simulations I cant no= t >>> provide that.We simulate lots of users and dont log all the GCC related >>> variables. >>> >>> However, I have attached simulation logs from two test cases- >>> 1. a staircase bandwidth test , that I found interesting in one of the >>> papers. >>> 2. and test case 5.1 from >>> http://tools.ietf.org/html/draft-sarker-rmcat-eval-test-01. >>> >>> I hope those plots will give you an idea about the implementation we ha= ve >>> and how it is behaving. >>> >>> I would suggest you run tests from >>> http://tools.ietf.org/html/draft-sarker-rmcat-eval-test-01 as well and = then >>> we can compare the results. >>> >>> BR >>> >>> Zahed >>> >>> >>> On 2014-06-25 17:32, Luca De Cicco wrote: >>>> >>>> Dear Zahed, >>>> >>>> can you share some information about the GCC simulation code? >>>> >>>> thanks, >>>> Luca >>>> >>>> >>>> On Wed, Jun 25, 2014 at 2:46 PM, Ingemar Johansson S >>>> >>> > wrote: >>>> >>>> Hi____ >>>> >>>> __ __ >>>> >>>> Thanks for the interest in this work. ____ >>>> >>>> __ __ >>>> >>>> Crosspost to RMCAT as well, hope that is Ok____ >>>> >>>> Answers/comments inline____ >>>> >>>> __ __ >>>> >>>> /Ingemar____ >>>> >>>> __ __ >>>> >>>> *From:*Luca De Cicco [mailto:ldecicco@gmail.com >>>> ] >>>> *Sent:* den 25 juni 2014 13:23 >>>> *To:* Ingemar Johansson S >>>> *Cc:* Dave Taht; iccrg@irtf.org >>>> *Subject:* Re: [iccrg] draft-johansson-rmcat-scream-cc____ >>>> >>>> __ __ >>>> >>>> Dear Ingemar,____ >>>> >>>> __ __ >>>> >>>> I have some questions. ____ >>>> >>>> __ __ >>>> >>>> 1) In the architecture figure (Figure 2) you show the case of two >>>> videos produced by the ____ >>>> >>>> same source and going to the same destination (both videos are >>>> encoded and fed to the same UDP socket),____ >>>> >>>> am I right? In the case SCReAM is used in a WebRTC context (in a >>>> browser), what use case ____ >>>> >>>> are you imagining?____ >>>> >>>> [IJ] This was just to highlight how two sources are handled, I am >>>> fully aware that it is probably not the most common use case, on t= he >>>> other hand I don=E2=80=99t know how WebRTC will be used in the fut= ure. If >>>> there are two destinations then one will need to congestion contro= l >>>> contexts (one for each UDP socket). The bandwidth distribution may >>>> then be based on rate shaping but another, possibly more useful, >>>> option is to target the congestion window functions directly, for >>>> instance if the congetsion window for one flow is knocked down jus= t >>>> a little then the other flow will grab the free capacity >>>> automatically. Another option is to adjust the gain factors for th= e >>>> CWND calculations.____ >>>> >>>> __ __ >>>> >>>> 2) How did you implement GCC algorithm? Do you have a paper where = I >>>> can see the dynamics of GCC (for instance____ >>>> >>>> the rate computed by the receiver side controller, the estimated o= ne >>>> way queuing delay variation "m")?____ >>>> >>>> [IJ] The GCC algorithm was implemented into our simulation platfor= m >>>> by Zahed, it is based in the availabe code and the drafts. We have >>>> logging possibilities in our simulator but I don=E2=80=99t know of= any paper >>>> around this.____ >>>> >>>> __ __ >>>> >>>> 3) You show average bitrate in the tables. There's an odd situatio= n >>>> where GCC gets a 50% packet loss ratio in the case of____ >>>> >>>> 16 users/cell but with an average rate of 61 kbps. Can you elabora= te >>>> on this?____ >>>> >>>> [IJ] Could be an effect of a much too high load in combination wit= h >>>> a high mobility, could be an effect of large amount of packet loss= es >>>> due to network queue overflow. I will BTW update the evaluation >>>> results for GCC soon, it seems like it was tuned a but too >>>> sensitive, with the new setting one get higher bitrates, but >>>> unfortunately also the tail latency will increase more quickly wit= h >>>> increased load. ____ >>>> >>>> __ __ >>>> >>>> Cheers,____ >>>> >>>> Luca____ >>>> >>>> __ __ >>>> >>>> On Wed, Jun 18, 2014 at 11:37 AM, Ingemar Johansson S >>>> >>> > wrote:____ >>>> >>>> Hi >>>> >>>> Besides the example code there is no ready to compile code availab= le >>>> (at least nothing that I know of). But on the other hand the >>>> solution has similarities to TFWC (TCP Friendly Window-based >>>> Congestion control) that was devised by Soo-Hyun Choi >>>> (http://tfwc.hackerslab.eu/ ), perhaps that can be used as a basis= ? >>>> >>>> /Ingemar____ >>>> >>>> >>>> > -----Original Message----- >>>> > From: Dave Taht [mailto:dave.taht@gmail.com >>>> ] >>>> > Sent: den 17 juni 2014 20:00 >>>> > To: Ingemar Johansson S >>>> > Cc: iccrg@irtf.org >>>> > Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc >>>> > >>>> > My usual request: Is there running code somewhere? >>>> > >>>> > On Tue, Jun 17, 2014 at 10:35 AM, 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 : =E2=80=9CThis memo describes a rate adaptation fra= mework for >>>> > > conversational >>>> > > >>>> > > video services. The solution conforms to the packet >>>> conservation >>>> > > >>>> > > principle and uses a hybrid loss and delay based congestio= n >>>> 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=E2=80=9D >>>> > > >>>> > > >>>> > > >>>> > > /Ingemar >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > > >>>> > > Ingemar Johansson M.Sc. >>>> > > >>>> > > Senior Researcher >>>> > > >>>> > > >>>> > > >>>> > > Ericsson AB >>>> > > >>>> > > Wireless Access Networks >>>> > > >>>> > > Labratoriegr=C3=A4nd 11 >>>> > > >>>> > > 971 28, Lule=C3=A5, Sweden >>>> > > >>>> > > Phone +46-1071 43042 >>>> > > >>>> > > SMS/MMS +46-73 078 3289 >>>> > > >>>> > > ingemar.s.johansson@ericsson.com >>>> >>>> > > >>>> > > www.ericsson.com >>>> > > >>>> > > >>>> > > >>>> > > =E2=80=9CThe difference between stupidity and >>>> > > >>>> > > genius is that genius has its limits." >>>> > > Albert Einstein >>>> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > iccrg mailing list >>>> > > iccrg@irtf.org >>>> > > https://www.irtf.org/mailman/listinfo/iccrg >>>> > > >>>> > >>>> > >>>> > >>>> > -- >>>> > Dave T=C3=A4ht >>>> > >>>> > NSFW: >>>> > >>>> >>>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_i= ndec >>>> > ent.article >>>> _______________________________________________ >>>> iccrg mailing list >>>> iccrg@irtf.org >>>> https://www.irtf.org/mailman/listinfo/iccrg____ >>>> >>>> __ __ >>>> >>>> >>> >>> -- >>> >>> Zahed >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> ANM ZAHEDUZZAMAN SARKER >>> >>> >>> Ericsson AB >>> Services, Media and Network Features >>> Laboratoriegr=C3=A4nd 11 >>> 97128 Lule=C3=A5, Sweden >>> Phone +46 10 717 37 43 >>> Fax +46 920 996 21 >>> SMS/MMS +46 76 115 37 43 >>> zaheduzzaman.sarker@ericsson.com >>> www.ericsson.com >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> >>> _______________________________________________ >>> iccrg mailing list >>> iccrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/iccrg >>> > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Wed Jul 16 11:06:15 2014 Return-Path: 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 ECA111A01A5 for ; Wed, 16 Jul 2014 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 deypSliByCTi for ; Wed, 16 Jul 2014 11:06:02 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5E51A01A8 for ; Wed, 16 Jul 2014 11:06:00 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X7TaY-0002xj-88; Wed, 16 Jul 2014 20:05:58 +0200 Received: from 089144238099.atnat0047.highway.bob.at ([89.144.238.99] helo=[192.168.0.103]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1X7TaW-0000IT-Ml; Wed, 16 Jul 2014 20:05:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 16 Jul 2014 20:05:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> <8B1B16F2-3E29-4817-9B22-F76E9957AEFA@ifi.uio.no> To: Varun Singh X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 10 sum msgs/h 3 total rcpts 18365 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 22954BA2959427E20F25B16774D2041C027239F9 X-UiO-SPAM-Test: remote_host: 89.144.238.99 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/HEbKcOIeQSIWjkTdSTr4W48cDa8 Cc: rmcat WG Subject: Re: [rmcat] Please review draft-ietf-rmcat-eval-criteria-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 18:06:11 -0000 Hi, In line: On 14. juli 2014, at 16:37, Varun Singh wrote: > Hi Michael, >=20 > Missed this email from earlier, comments inline. >=20 > Cheers, > Varun >=20 > On Fri, Jun 13, 2014 at 4:07 PM, Michael Welzl = wrote: >> Hi, >>=20 >> On 12. juni 2014, at 13:28, Varun Singh wrote: >>=20 >>> Hi all, >>>=20 >>> There was one one open issue that needs to be discussed and it is >>> related to fairness :) >>>=20 >>> This has been discussed at length in the design group meetings and >>> also at the IETF meetings, but I am not sure if the text in the open >>> issue had working group agreement. >>>=20 >>> The summary of the discussion so far is: >>> - The eval-criteria needs to define a guideline that helps in >>> evaluating an RMCAT proposal >>> - The individual test case should define its expected fairness >>> criteria, and it may vary between scenarios. >>>=20 >>> NEW TEXT to replace the open issue: >>>=20 >>> Fairness or Unfairness: Experiments testing the performance of an >>> RMCAT proposal against any cross-traffic must define its expected >>> criteria for fairness. >>>=20 >>> The "unfairness" test guideline to assist in defining such a >>> criteria (measured at 1s intervals) is: >>> 1. Does not trigger the circuit breaker. >>> 2. When the competing streams with identical RMCAT streams having >>> similar RTTs, >>> no stream achieves over 3 times the min RMCAT stream or less than >>> 1/3 times the >>> throughput of the max RMCAT stream. >>=20 >> In principle, what this new text up to here is trying to say (if I = interpret it correctly) sounds good to me. >> However, the English is pretty broken, please fix. >>=20 >=20 > 2. When competing with identical RMCAT streams having similar RTTs, > no RMCAT stream achieves > more than 3 times the average throughput of the RMCAT stream with the > lowest average throughput, > or less than 1/3 times the average throughput of the RMCAT stream with > the highest average throughput. Looks fine to me >>> 3. When competing with identical RMCAT streams having similar = RTTs, >>> no RTT measurements for an RMCAT stream is over 3 times delay = compared to RTT >>> measurements performed before starting the RMCAT flow. >>=20 >> Huh? "Compared to measurements performed before starting the RMCAT = flow" =3D> which one? All, including the background flows, or only the = foreground flow? The foreground flow must not make the RTT grow by a = factor of 3, is that it? I think that's not a fairness criterion, it's a = delay-minimizing criterion, and a weird one too. I wonder if this could = just be removed. >=20 > My interpretation of the proposal was that the RTT should not grow by > a factor of 3 for the existing flows when a new flow is added. I can > remove this, if there is consensus on removing this requirement. Ah, got it. I'm fine with the requirement (although I stick with my = observation that it's kinda weird :) ). Anyway I'd rephrase it as you = wrote it here, which is much easier to understand than your original = text. Cheers, Michael > I do not remember correctly who made the original proposal (was > perhaps Kevin Gross), but was in a design meeting from a year ago. >=20 >>=20 >> Cheers, >> Michael >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From nobody Thu Jul 17 04:24:27 2014 Return-Path: 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 8FB2D1A0ADD for ; Thu, 17 Jul 2014 04:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 PRoAOUwtFWpO for ; Thu, 17 Jul 2014 04:24:23 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0211A0ADA for ; Thu, 17 Jul 2014 04:24:19 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so2441361wes.10 for ; Thu, 17 Jul 2014 04:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=JWGWAtZ9a1hA3x6ZSaOxkOslVtl6hdMpFIzZ6w6lRVI=; b=smQ1jNVTI/GfxZNy+Hlm+BAlsGxNWjHhmah7YWwL+GbXL/o0iIT5hZBvPxXwAEJ9K6 Diru1Mq2S8OgiEyeLoxEezpkSMixlvxxxv2YNpXzY6yI/Nps/3f11O1kScQhAt8wsITd aA+Nywhh1RI869lizNm78T/fRCkxvQ8z0qvABbdFwceaDPKg7pvFHblbYGA+/0YZbCya dvAWafshhlNjHxd1L7UDJKzZTboYTg27VqIPtwLfk7ApxYCpAraaW2n1hUJC5+s3YTxQ IW1r6Lv+xbI5rayzHp7PGiPFxfko+mmBhOFYngvcAyTCjbJV7j8YK6PqFQHgjdHbXsjJ ioeg== X-Received: by 10.180.103.228 with SMTP id fz4mr20924472wib.4.1405596258018; Thu, 17 Jul 2014 04:24:18 -0700 (PDT) Received: from black.lan (bcdeefe5.skybroadband.com. [188.222.239.229]) by mx.google.com with ESMTPSA id fg1sm19998676wic.17.2014.07.17.04.24.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 04:24:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0609BFB9-F27C-4850-8253-54769DB71992" From: Piers O'Hanlon In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> Date: Thu, 17 Jul 2014 12:24:14 +0100 Message-Id: <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> To: Ingemar Johansson S , Zaheduzzaman Sarker X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/p2-lnzsKqpP-q5SVmXX1o4hvZA4 Cc: rmcat WG , iccrg@irtf.org Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 11:24:25 -0000 --Apple-Mail=_0609BFB9-F27C-4850-8253-54769DB71992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ignemar 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. - 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? - 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...? - 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? - How does it compete against a LEDBAT flow with a similar target? Cheers, Piers On 17 Jun 2014, at 18:35, Ingemar Johansson S wrote: > Hi > =20 > 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= > =20 > Abstract : =93This 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=94 > =20 > /Ingemar > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > =93The difference between stupidity and > genius is that genius has its limits." > Albert Einstein > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 >=20 > =20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg --Apple-Mail=_0609BFB9-F27C-4850-8253-54769DB71992 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Ignemar 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.
- 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?
- 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...?
- 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?
- How = does it compete against a LEDBAT flow with a similar = target?

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.
 
The difference = between stupidity and
genius is that genius has its limits."Albert Einstein
 

 
___________________________________________= ____
iccrg mailing list
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:46:49 -0000 Hi Michael, Snipping away the original email, comment inline. >> >> 2. When competing with identical RMCAT streams having similar RTTs, >> no RMCAT stream achieves >> more than 3 times the average throughput of the RMCAT stream with the >> lowest average throughput, >> or less than 1/3 times the average throughput of the RMCAT stream with >> the highest average throughput. > > Looks fine to me > Will add this in the next update. > >>>> 3. When competing with identical RMCAT streams having similar RTTs, >>>> no RTT measurements for an RMCAT stream is over 3 times delay compare= d to RTT >>>> measurements performed before starting the RMCAT flow. >>> >>> Huh? "Compared to measurements performed before starting the RMCAT flow= " =3D> which one? All, including the background flows, or only the foregrou= nd flow? The foreground flow must not make the RTT grow by a factor of 3, i= s that it? I think that's not a fairness criterion, it's a delay-minimizing= criterion, and a weird one too. I wonder if this could just be removed. >> >> My interpretation of the proposal was that the RTT should not grow by >> a factor of 3 for the existing flows when a new flow is added. I can >> remove this, if there is consensus on removing this requirement. > > Ah, got it. I'm fine with the requirement (although I stick with my obser= vation that it's kinda weird :) ). Anyway I'd rephrase it as you wrote it= here, which is much easier to understand than your original text. > I can fix the text as suggest above. Alternatively, I am wondering if this should be expressed as a function of queuing delay? i.e., QD =3D RTT_measured - RTT_base. RTT_base is the configured value in the testbed/simulator. I can't think of a good enough value here either. Suggestions are welcome. I suppose another way to measure this is if the endpoint starts to discard late arriving packets, then we may not have to worry about the delay metric. This however implies that the simulator/testbed has a playout buffer or some model to simulate it. > Cheers, > Michael > > > >> I do not remember correctly who made the original proposal (was >> perhaps Kevin Gross), but was in a design meeting from a year ago. >> >>> >>> Cheers, >>> Michael >>> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Thu Jul 17 10:28:21 2014 Return-Path: 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 D4DDA1A0022 for ; Thu, 17 Jul 2014 10:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 VS6DHgo4mtts for ; Thu, 17 Jul 2014 10:27:19 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555C01A000B for ; Thu, 17 Jul 2014 10:27:19 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X7pSf-0000Eo-DM; Thu, 17 Jul 2014 19:27:17 +0200 Received: from 089144238099.atnat0047.highway.bob.at ([89.144.238.99] helo=[192.168.0.103]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X7pSd-00056o-5x; Thu, 17 Jul 2014 19:27:17 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_9ECA54A8-426D-4A78-9F89-5683B8A94022" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Thu, 17 Jul 2014 19:27:11 +0200 Message-Id: <41BA4E9A-6D33-474D-BA74-05494BA5568F@ifi.uio.no> References: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> <8B1B16F2-3E29-4817-9B22-F76E9957AEFA@ifi.uio.no> To: Varun Singh X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 3 sum msgs/h 2 total rcpts 18376 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F6C200917CF588BB1281D178EB283C8D5B2A1D67 X-UiO-SPAM-Test: remote_host: 89.144.238.99 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/SWxi7X7J9brUqzddyOBtzl_fHl8 Cc: rmcat WG Subject: Re: [rmcat] Please review draft-ietf-rmcat-eval-criteria-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 17:27:23 -0000 --Apple-Mail=_9ECA54A8-426D-4A78-9F89-5683B8A94022 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17. juli 2014, at 18:46, Varun Singh wrote: > Hi Michael, >=20 > Snipping away the original email, comment inline. >=20 >>>=20 >>> 2. When competing with identical RMCAT streams having similar RTTs, >>> no RMCAT stream achieves >>> more than 3 times the average throughput of the RMCAT stream with = the >>> lowest average throughput, >>> or less than 1/3 times the average throughput of the RMCAT stream = with >>> the highest average throughput. >>=20 >> Looks fine to me >>=20 >=20 > Will add this in the next update. >=20 >>=20 >>>>> 3. When competing with identical RMCAT streams having similar = RTTs, >>>>> no RTT measurements for an RMCAT stream is over 3 times delay = compared to RTT >>>>> measurements performed before starting the RMCAT flow. >>>>=20 >>>> Huh? "Compared to measurements performed before starting the RMCAT = flow" =3D> which one? All, including the background flows, or only the = foreground flow? The foreground flow must not make the RTT grow by a = factor of 3, is that it? I think that's not a fairness criterion, it's a = delay-minimizing criterion, and a weird one too. I wonder if this could = just be removed. >>>=20 >>> My interpretation of the proposal was that the RTT should not grow = by >>> a factor of 3 for the existing flows when a new flow is added. I can >>> remove this, if there is consensus on removing this requirement. >>=20 >> Ah, got it. I'm fine with the requirement (although I stick with my = observation that it's kinda weird :) ). Anyway I'd rephrase it as you = wrote it here, which is much easier to understand than your original = text. >>=20 >=20 > I can fix the text as suggest above. >=20 > Alternatively, I am wondering if this should be expressed as a > function of queuing delay? i.e., QD =3D RTT_measured - RTT_base. > RTT_base is the configured value in the testbed/simulator. I can't > think of a good enough value here either. Suggestions are welcome. I'd keep it simple and not go there. Anyway the 3x thing is pretty = dubious - depends on queue lengths and whatnot; thus, best not to dig = into the details, this is only asking for trouble :-) Cheers, Michael > I suppose another way to measure this is if the endpoint starts to > discard late arriving packets, then we may not have to worry about the > delay metric. This however implies that the simulator/testbed has a > playout buffer or some model to simulate it. >=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >>> I do not remember correctly who made the original proposal (was >>> perhaps Kevin Gross), but was in a design meeting from a year ago. >>>=20 >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> http://www.netlab.tkk.fi/~varun/ >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ --Apple-Mail=_9ECA54A8-426D-4A78-9F89-5683B8A94022 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Michael,

Snipping away = the original email, comment inline.


2. When competing with = identical RMCAT streams having similar RTTs,
no RMCAT stream = achieves
more than 3 times the average throughput of the RMCAT stream = with the
lowest average throughput,
or less than 1/3 times the = average throughput of the RMCAT stream with
the highest average = throughput.

Looks fine to = me


Will add this in the next = update.


3. =  When competing with identical RMCAT streams having similar = RTTs,
no RTT measurements for an RMCAT stream is over 3 times delay = compared to RTT
measurements performed before starting the RMCAT = flow.

Huh? "Compared to measurements performed = before starting the RMCAT flow" =3D> which one? All, including the = background flows, or only the foreground flow? The foreground flow must = not make the RTT grow by a factor of 3, is that it? I think that's not a = fairness criterion, it's a delay-minimizing criterion, and a weird one = too. I wonder if this could just be removed.

My = interpretation of the proposal was that the RTT should not grow by
a = factor of 3 for the existing flows when a new flow is added. I = can
remove this, if there is consensus on removing this = requirement.

Ah, got it. I'm fine with the = requirement (although I stick with my observation that it's kinda weird =  :)  ). Anyway I'd rephrase it as you wrote it here, which is = much easier to understand than your original = text.


I can fix the text as suggest = above.

Alternatively, I am wondering if this should be expressed = as a
function of queuing delay? i.e., QD =3D RTT_measured - = RTT_base.
RTT_base is the configured value in the testbed/simulator. = I can't
think of a good enough value here either. Suggestions are = welcome.

I'd keep it simple and not = go there. Anyway the 3x thing is pretty dubious - depends on queue = lengths and whatnot; thus, best not to dig into the details, this is = only asking for trouble =  :-)

Cheers,
Michael

I = suppose another way to measure this is if the endpoint starts = to
discard late arriving packets, then we may not have to worry about = the
delay metric. This however implies that the simulator/testbed has = a
playout buffer or some model to simulate it.

Cheers,
Michael



I do not remember correctly who made the original proposal = (was
perhaps Kevin Gross), but was in a design meeting from a year = ago.


Cheers,
Michael




--http://www.netlab.tkk.fi/~varun/=




-- 
http://www.netlab.tkk.fi/~varun/=

= --Apple-Mail=_9ECA54A8-426D-4A78-9F89-5683B8A94022-- From nobody Thu Jul 17 11:56:13 2014 Return-Path: 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 61C221A009C for ; Thu, 17 Jul 2014 11:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 hB3cl1vwc-Vy for ; Thu, 17 Jul 2014 11:53:26 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBF51A0002 for ; Thu, 17 Jul 2014 11:53:25 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-03-53c81ba320b2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.C1.04090.3AB18C35; Thu, 17 Jul 2014 20:53:23 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Thu, 17 Jul 2014 20:53:23 +0200 From: Ingemar Johansson S To: Piers O'Hanlon , Zaheduzzaman Sarker Thread-Topic: [iccrg] draft-johansson-rmcat-scream-cc Thread-Index: AQHPobGmDgx3xF9lZUi4Obdy1L0unJukku8w Date: Thu, 17 Jul 2014 18:53:21 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> In-Reply-To: <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> 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: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvje5i6RPBBnNXy1gcWLCT3WLfjImM FqtvfmBzYPbYOesuu8eSJT+ZPCZvPMwWwBzFZZOSmpNZllqkb5fAldF+M7bgwnbGij9X1zE3 MG5ezNjFyMkhIWAi8f/bcTYIW0ziwr31QDYXh5DAUUaJO1seMUE4ixklOvZeYwGpYhOwkVh5 6DtYt4hAksTqbxOZQWxmgRqJxxu3sILYwkBTX32cwQZRYyrxdulaKNtI4uqEE2BzWARUJWbe hdjMK+ArsfrgWajNDYwSf49fBiri4OAUsJVYPSsDpIZRQFbi/vd7LBC7xCVuPZnPBHG1gMSS PeeZIWxRiZeP/7FC2EoSaw9vh6rPl3ja/4MJYpegxMmZT1gmMIrOQjJqFpKyWUjKIOJ6Ejem TmGDsLUlli18zQxh60rM+HeIBVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAODy4 5bfVDsaDzx0PMQpwMCrx8CrwnwgWYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MtgUz4lXUHkTKVx+7uvj3/JLHonne3QmiOySivpv0NumzMq+KUV+cIjRB w8zVqX21p56Htnl6A3MhZ93t7U2H30tGLvZ97DfzzvFrt5drfAyU6uo5Oq8i4XmykOFrfob5 s/V4EvcIL1Bddm1O5m+fx1tfcmfuuOXPaDvv/Grt7q9drfwfp+1UYinOSDTUYi4qTgQAmvkx jaQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/cLpqKm2h4o4y5RgRf4eJpqvNlRI Cc: Ingemar Johansson S , rmcat WG , "iccrg@irtf.org" Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:53:30 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thanks for the interest in this contribution. Answers/comments inline. Regards Ingemar From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com] Sent: den 17 juli 2014 13:24 To: Ingemar Johansson S; Zaheduzzaman Sarker Cc: iccrg@irtf.org; 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 adv= antage, delay-impact on other flows, and yielding behaviour to short of lon= ger lived TCP flows etc. [IJ] Zahed will present a few test cases at the RMCAT WG sessions. A few ad= ditional comments. Yes, I have see similar issues that are reported for LED= BAT in terms of late comers advantage etc. also in SCReAM, the current solu= tion 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 p= eriod. 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 do= n'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 gi= ven in the presentation. - 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 TARGE= T 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 t= he code, the adaptive delay target function use the same technique to put t= he 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 th= is is an indication that the delay target can be increased. - 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 LED= BAT, will look it up when I am back from the vacation for good in mid Augus= t - What sort of filtering do you propose for queuing delay beyond MIN - Mobi= le provides for very noisy environments I wondered if you had any alternati= ves? [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 adjustmen= t. - 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. 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 con= trol 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 conversatio= nal 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "The difference between stupidity and genius is that genius has its limits." Albert Einstein =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ iccrg mailing list iccrg@irtf.org https://www.irtf.org/mailman/listinfo/iccrg --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

Thanks for the interest i= n this contribution. Answers/comments inline.

 <= /p>

Regards=

Ingemar=

 <= /p>

From: Piers O'= Hanlon [mailto:p.ohanlon@gmail.com]
Sent: den 17 juli 2014 13:24
To: Ingemar Johansson S; Zaheduzzaman Sarker
Cc: iccrg@irtf.org; rmcat WG
Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc

 

Hi Ingemar and&= nbsp;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 yo= u had looked into some of the issues it suffers from like; intra-procotol f= airness, late-comer advantage, delay-impact on other flows, and yielding be= haviour 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 t= o this is to put media on hold for about one RTT at regular intervals if th= e 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.

 <= /p>

- It is mentioned that there's an 'Adaptive delay ta= rget' - but in the code owdTarget does not change - Did you have strat= egies 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 no= t yet any adaptive target delay functionality in the code, the adaptive del= ay 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 the= re are competing flows then the OWD will not drop that much, and this is an= indication that the delay target can be increased.

- What period do use to measure the Base Delay (or d= o use LEDBAT's 1 minute value) - the default seems quite high for mobile de= ployments...?

[IJ] Don’t remember= right now but it is definitely shorter than default LEDBAT, will look it u= p when I am back from the vacation for good in mid August=

- What sort of filtering do you propose for queuing = delay beyond MIN - Mobile provides for very noisy environments I wondered i= f you had any alternatives?

[IJ] Yes it is noisy but = sofar I don’t use any filtering at all, seems like it is sufficient w= ith the filtering that is inherent in the CWND adjustment.

- How does it compete against a LEDBAT flow with a s= imilar 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.

 

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.

 

Abstract : “This memo describes a= rate adaptation framework for conversational

   video services.  The = solution conforms to the packet conservation

   principle and uses a hybri= d loss and delay based congestion control

   algorithm.  The frame= work is evaluated over both simulated bottleneck

   scenarios as well as in a = LTE (Long Term Evolution) system simulator

   and is shown to achieve bo= th low latency and high video throughput in

   these scenariosR= 21;

 <= o:p>

/Ingemar

 <= o:p>

 <= o:p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.=

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11<= o:p>

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 

“The difference between stupidity and<= o:p>

genius is th= at genius has its limits."
Albert Einstein
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

 

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.or= g/mailman/listinfo/iccrg

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290ESESSMB205erics_-- From nobody Sun Jul 20 13:49:16 2014 Return-Path: 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 C67041B2C9C for ; Sun, 20 Jul 2014 13:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no 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 gofB8oyHwn4j for ; Sun, 20 Jul 2014 13:49:11 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CA01B295B for ; Sun, 20 Jul 2014 13:49:09 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so6703520wes.20 for ; Sun, 20 Jul 2014 13:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=bjGdpLa5EMjiV1cfvZf51tRlfzaYLUGoT3ySyvxZX3g=; b=NbArzXRklGBFjiPydndfeiHQPdj/q1dO5TFumZFH+fwHV8PbE6LbCRtV6apdl4WyM3 DOTYXPM+nEinE8mKL5bonbB9yJ8kd4gUy1rNYhqG/I32cUvve0llU/0QDnDwqRv4nD9k c6iA0d4agNBVQA4HFyiJTxRsRM+tpQ5pGgys8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=bjGdpLa5EMjiV1cfvZf51tRlfzaYLUGoT3ySyvxZX3g=; b=DhfuKl5hY0vhNTyTTKl43LqKLTmKSwiR9oRPB1co0ywxyfz3uNFZFgqwRbDDCJFAtH uHN5vdn+DDksx+lrI96/UD1RrDmRDye3ixy0j6v/fGE5bHtMzvPt33Ugpb6J1aKjTUG1 Rp4QpYMTfBSGEf/ETrRrWsuM48BJhtlUE+3OsiJZcsWEumCxDwniMKUzicOvWzSRoTcx fCT7ksBmTbnc4hVAGM1WhZ9EhjUc2hp0xL53/saCxyRo86/VersJQXcAVPJVv96TQBzU frN7PfZ7W/UIFXNm0GuuIJF+8Ztibq4ITEW22Aj26SwjZKe9tOYa9IFjTdUTvZPEV5s6 OlhA== X-Gm-Message-State: ALoCoQmo2heHYdC/yUsS8O1Zth8+1Ci/ey0ZHdLTkArvwTDj/pAroXY2KsrfMlSaV9uf0xv9WTEhppAdSO/0+DVcZS9IuuBU9w== X-Received: by 10.180.12.38 with SMTP id v6mr7173588wib.31.1405889348485; Sun, 20 Jul 2014 13:49:08 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> In-Reply-To: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeZlmc0rg Date: Sun, 20 Jul 2014 22:49:13 +0200 Message-ID: <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> To: tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/8qujUp6BFAotmFMKjvlF-1TuhsY Cc: rmcat WG Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:49:13 -0000 Hi, Please accept the following comments: I wonder if the recommendations of this document should not relate to the viability (or rather the opposite) of handling different RTCWEB data channels individually from a DSCP markings perspective. Or more generally relate to the fact that media streams within the same congestion control context cannot be handled individually. Right now such considerations are not in the document. If the intention is for such consideration to come in documents from the dart wg, then it would be very important to have a reference to this dependency - or ? Something else: Right now the document stipulates that packets within the same media stream may be marked with different DSCP codepoints, i.e., it is said: One may select difference drop precedences for the different packets in the media flow. Therefore, all packets in the stream SHOULD be marked with the same priority but can have difference drop precedences. which indeed is in compliance with the recommendations put forward in draft-york-dart-dscp-rtp-00 in that it ensures that the DSCP markings do not result in re-ordering within the media flow, but has it been ascertained, from a CC perspective that usage of different drop precedence within the same CC context is viable ? >From the RTCWEB data channel perspective this certainly isn't viable (being SCTP based), whether it is viable from an RMCAT CC perspective is something that we in the RMCAT wg would need to make more clear. BR, Karen > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 23. juni 2014 21:12 > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Area Working Group Working > Group of the IETF. > > Title : DSCP and other packet markings for RTCWeb QoS > Authors : Subha Dhesikan > Cullen Jennings > Dan Druta > Paul Jones > James Polk > Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt > Pages : 7 > Date : 2014-06-23 > > Abstract: > Many networks, such as service provider and enterprise networks, can > provide per packet treatments based on Differentiated Services Code > Points (DSCP) on a per-hop basis. This document provides the > recommended DSCP values for browsers to use for various classes of > traffic. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 20 17:51:38 2014 Return-Path: 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 5B3741B2A70; Sun, 20 Jul 2014 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 57ZS7kBKMGWK; Sun, 20 Jul 2014 17:51:28 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015891B2A68; Sun, 20 Jul 2014 17:51:27 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L0pPFL027100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 20:51:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s6L0pPFL027100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405903886; bh=SVxmqDBMJhw8MNqyAIwU+C/X6xI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Zjwtj2BxbKoWPlK4SjQpSWbFFftWKq3gVw1QVXnlC+YS+fAaJzQezapIzC+yPSiTJ JtQc5BnDqpkgOGXwFeH//xv4waMDrn3Qj1cM2ifZyKxiFh4DRRUO7buyTG/Av5iPyw ee24S4YX/bB8GWHh6DqAZa2ATzMrebKta2cQQAGs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s6L0pPFL027100 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Sun, 20 Jul 2014 20:51:15 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L0pEEA001721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jul 2014 20:51:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Sun, 20 Jul 2014 20:51:14 -0400 From: "Black, David" To: "Karen E. Egede Nielsen" , "tsvwg@ietf.org" Date: Sun, 20 Jul 2014 20:51:12 -0400 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeZlmc0rggABeiUA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> In-Reply-To: <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/GabVC-I19HiWP6JFJJQHk8t3GoM Cc: rmcat WG , "Black, David" , "dart@ietf.org" Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:51:30 -0000 S2FyZW4sDQoNCjxXRyBjaGFpciBoYXQgb2ZmPiwgWytkYXJ0IGxpc3RdDQoNCj4gSSB3b25kZXIg aWYgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHNob3VsZCBub3QgcmVsYXRl IHRvIHRoZQ0KPiB2aWFiaWxpdHkgKG9yIHJhdGhlciB0aGUgb3Bwb3NpdGUpIG9mDQo+IGhhbmRs aW5nIGRpZmZlcmVudCBSVENXRUIgZGF0YSBjaGFubmVscyBpbmRpdmlkdWFsbHkgZnJvbSBhIERT Q1AgbWFya2luZ3MNCj4gcGVyc3BlY3RpdmUuIE9yIG1vcmUgZ2VuZXJhbGx5DQo+IHJlbGF0ZSB0 byB0aGUgZmFjdCB0aGF0IG1lZGlhIHN0cmVhbXMgd2l0aGluIHRoZSBzYW1lIGNvbmdlc3Rpb24g Y29udHJvbA0KPiBjb250ZXh0IGNhbm5vdCBiZSBoYW5kbGVkIGluZGl2aWR1YWxseS4NCj4gUmln aHQgbm93IHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBpbiB0aGUgZG9jdW1lbnQuIElmIHRo ZSBpbnRlbnRpb24gaXMNCj4gZm9yIHN1Y2ggY29uc2lkZXJhdGlvbiB0byBjb21lDQo+IGluIGRv Y3VtZW50cyBmcm9tIHRoZSBkYXJ0IHdnLCB0aGVuIGl0IHdvdWxkIGJlIHZlcnkgaW1wb3J0YW50 IHRvICBoYXZlIGENCj4gcmVmZXJlbmNlIHRvIHRoaXMgZGVwZW5kZW5jeSAtIG9yID8NCg0KSU1I Tywgc3VjaCBhIHJlZmVyZW5jZSBpcyBuZWNlc3NhcnksIGFsdGhvdWdoIHRoZSBkYXJ0IFdHIGRy YWZ0IHdpbGwgYmUNCmluZm9ybWF0aW9uYWwuICBUaGUgcmVmZXJlbmNlIHNob3VsZCBiZSBhZGRl ZCBvbmNlIHRoZXJlIGlzIGFuIG9mZmljaWFsIGRhcnQNCldHIGRyYWZ0IChsaWtlbHkgdG8gaGFw cGVuIHRoaXMgd2VlaykuDQoNCj4gU29tZXRoaW5nIGVsc2U6DQo+DQo+IFJpZ2h0IG5vdyB0aGUg ZG9jdW1lbnQgc3RpcHVsYXRlcyB0aGF0IHBhY2tldHMgd2l0aGluIHRoZSBzYW1lIG1lZGlhIHN0 cmVhbQ0KPiBtYXkgYmUgbWFya2VkIHdpdGggZGlmZmVyZW50IERTQ1AgY29kZXBvaW50cywgaS5l LiwNCj4gaXQgaXMgc2FpZDoNCj4gDQo+ICAgIE9uZSBtYXkgc2VsZWN0IGRpZmZlcmVuY2UgZHJv cCBwcmVjZWRlbmNlcyBmb3IgdGhlDQo+ICAgIGRpZmZlcmVudCBwYWNrZXRzIGluIHRoZSBtZWRp YSBmbG93LiAgVGhlcmVmb3JlLCBhbGwgcGFja2V0cyBpbiB0aGUNCj4gICAgc3RyZWFtIFNIT1VM RCBiZSBtYXJrZWQgd2l0aCB0aGUgc2FtZSBwcmlvcml0eSBidXQgY2FuIGhhdmUNCj4gICAgZGlm ZmVyZW5jZSBkcm9wIHByZWNlZGVuY2VzLg0KPiANCj4gd2hpY2ggaW5kZWVkIGlzIGluIGNvbXBs aWFuY2Ugd2l0aCB0aGUgcmVjb21tZW5kYXRpb25zIHB1dCBmb3J3YXJkIGluDQo+IGRyYWZ0LXlv cmstZGFydC1kc2NwLXJ0cC0wMCBpbiB0aGF0DQo+IGl0IGVuc3VyZXMgdGhhdCB0aGUgRFNDUCBt YXJraW5ncyAgZG8gbm90IHJlc3VsdCBpbiByZS1vcmRlcmluZyAgd2l0aGluIHRoZQ0KPiBtZWRp YSBmbG93LCBidXQgaGFzIGl0IGJlZW4gYXNjZXJ0YWluZWQsIGZyb20gYSBDQw0KPiBwZXJzcGVj dGl2ZSB0aGF0IHVzYWdlIG9mIGRpZmZlcmVudCBkcm9wIHByZWNlZGVuY2Ugd2l0aGluIHRoZSBz YW1lIENDDQo+IGNvbnRleHQgaXMgdmlhYmxlID8NCg0KR29vZCBxdWVzdGlvbiAtIEkgd2lsbCBp bmNsdWRlIHRoYXQgaW4gbXkgc2xpZGVzIGZvciB0aGUgZGFydCBXRyBtZWV0aW5nLg0KDQo+ID5G cm9tIHRoZSBSVENXRUIgZGF0YSBjaGFubmVsIHBlcnNwZWN0aXZlIHRoaXMgY2VydGFpbmx5IGlz bid0IHZpYWJsZSAoYmVpbmcNCj4gU0NUUCBiYXNlZCksDQo+IHdoZXRoZXIgaXQgaXMgdmlhYmxl IGZyb20gYW4gUk1DQVQgQ0MgcGVyc3BlY3RpdmUgaXMgc29tZXRoaW5nIHRoYXQgd2UgaW4NCj4g dGhlIFJNQ0FUIHdnIHdvdWxkIG5lZWQgdG8NCj4gbWFrZSBtb3JlIGNsZWFyLg0KDQpXaGF0J3Mg dGhlIHJhdGlvbmFsZSBmb3IgImNlcnRhaW5seSBpc24ndCB2aWFibGUiIHJlZ2FyZGluZyBkaWZm ZXJlbnQgZHJvcA0KcHJlY2VkZW5jZXMgd2l0aGluIGEgc2luZ2xlIFNDVFAgc2Vzc2lvbj8NCg0K VGhhbmtzLA0KLS1EYXZpZCAoYXMgYW4gZWRpdG9yIG9mIGRyYWZ0LXlvcmssICpub3QqIGFzIGEg dHN2d2cgV0cgY2hhaXIpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog dHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2FyZW4g RS4gRWdlZGUNCj4gTmllbHNlbg0KPiBTZW50OiBTdW5kYXksIEp1bHkgMjAsIDIwMTQgNDo0OSBQ TQ0KPiBUbzogdHN2d2dAaWV0Zi5vcmcNCj4gQ2M6IHJtY2F0IFdHDQo+IFN1YmplY3Q6IFJlOiBb dHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0wMi50eHQNCj4g DQo+IEhpLA0KPiANCj4gUGxlYXNlIGFjY2VwdCB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KPiAN Cj4gSSB3b25kZXIgaWYgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHNob3Vs ZCBub3QgcmVsYXRlIHRvIHRoZQ0KPiB2aWFiaWxpdHkgKG9yIHJhdGhlciB0aGUgb3Bwb3NpdGUp IG9mDQo+IGhhbmRsaW5nIGRpZmZlcmVudCBSVENXRUIgZGF0YSBjaGFubmVscyBpbmRpdmlkdWFs bHkgZnJvbSBhIERTQ1AgbWFya2luZ3MNCj4gcGVyc3BlY3RpdmUuIE9yIG1vcmUgZ2VuZXJhbGx5 DQo+IHJlbGF0ZSB0byB0aGUgZmFjdCB0aGF0IG1lZGlhIHN0cmVhbXMgd2l0aGluIHRoZSBzYW1l IGNvbmdlc3Rpb24gY29udHJvbA0KPiBjb250ZXh0IGNhbm5vdCBiZSBoYW5kbGVkIGluZGl2aWR1 YWxseS4NCj4gUmlnaHQgbm93IHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBpbiB0aGUgZG9j dW1lbnQuIElmIHRoZSBpbnRlbnRpb24gaXMNCj4gZm9yIHN1Y2ggY29uc2lkZXJhdGlvbiB0byBj b21lDQo+IGluIGRvY3VtZW50cyBmcm9tIHRoZSBkYXJ0IHdnLCB0aGVuIGl0IHdvdWxkIGJlIHZl cnkgaW1wb3J0YW50IHRvICBoYXZlIGENCj4gcmVmZXJlbmNlIHRvIHRoaXMgZGVwZW5kZW5jeSAt IG9yID8NCj4gDQo+IFNvbWV0aGluZyBlbHNlOg0KPiANCj4gUmlnaHQgbm93IHRoZSBkb2N1bWVu dCBzdGlwdWxhdGVzIHRoYXQgcGFja2V0cyB3aXRoaW4gdGhlIHNhbWUgbWVkaWEgc3RyZWFtDQo+ IG1heSBiZSBtYXJrZWQgd2l0aCBkaWZmZXJlbnQgRFNDUCBjb2RlcG9pbnRzLCBpLmUuLA0KPiBp dCBpcyBzYWlkOg0KPiANCj4gICAgT25lIG1heSBzZWxlY3QgZGlmZmVyZW5jZSBkcm9wIHByZWNl ZGVuY2VzIGZvciB0aGUNCj4gICAgZGlmZmVyZW50IHBhY2tldHMgaW4gdGhlIG1lZGlhIGZsb3cu ICBUaGVyZWZvcmUsIGFsbCBwYWNrZXRzIGluIHRoZQ0KPiAgICBzdHJlYW0gU0hPVUxEIGJlIG1h cmtlZCB3aXRoIHRoZSBzYW1lIHByaW9yaXR5IGJ1dCBjYW4gaGF2ZQ0KPiAgICBkaWZmZXJlbmNl IGRyb3AgcHJlY2VkZW5jZXMuDQo+IA0KPiB3aGljaCBpbmRlZWQgaXMgaW4gY29tcGxpYW5jZSB3 aXRoIHRoZSByZWNvbW1lbmRhdGlvbnMgcHV0IGZvcndhcmQgaW4NCj4gZHJhZnQteW9yay1kYXJ0 LWRzY3AtcnRwLTAwIGluIHRoYXQNCj4gaXQgZW5zdXJlcyB0aGF0IHRoZSBEU0NQIG1hcmtpbmdz ICBkbyBub3QgcmVzdWx0IGluIHJlLW9yZGVyaW5nICB3aXRoaW4gdGhlDQo+IG1lZGlhIGZsb3cs IGJ1dCBoYXMgaXQgYmVlbiBhc2NlcnRhaW5lZCwgZnJvbSBhIENDDQo+IHBlcnNwZWN0aXZlIHRo YXQgdXNhZ2Ugb2YgZGlmZmVyZW50IGRyb3AgcHJlY2VkZW5jZSB3aXRoaW4gdGhlIHNhbWUgQ0MN Cj4gY29udGV4dCBpcyB2aWFibGUgPw0KPiANCj4gPkZyb20gdGhlIFJUQ1dFQiBkYXRhIGNoYW5u ZWwgcGVyc3BlY3RpdmUgdGhpcyBjZXJ0YWlubHkgaXNuJ3QgdmlhYmxlIChiZWluZw0KPiBTQ1RQ IGJhc2VkKSwNCj4gd2hldGhlciBpdCBpcyB2aWFibGUgZnJvbSBhbiBSTUNBVCBDQyBwZXJzcGVj dGl2ZSBpcyBzb21ldGhpbmcgdGhhdCB3ZSBpbg0KPiB0aGUgUk1DQVQgd2cgd291bGQgbmVlZCB0 bw0KPiBtYWtlIG1vcmUgY2xlYXIuDQo+IA0KPiBCUiwgS2FyZW4NCj4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC0NCj4gPiBkcmFmdHNAaWV0Zi5vcmcNCj4g PiBTZW50OiAyMy4ganVuaSAyMDE0IDIxOjEyDQo+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPiA+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFt0c3Z3Z10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTAyLnR4dA0KPiA+DQo+ID4NCj4gPiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMNCj4gPiBkaXJlY3Rvcmllcy4NCj4gPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgVHJhbnNwb3J0IEFyZWEgV29ya2luZyBHcm91cCBXb3JraW5nDQo+ID4gR3JvdXAgb2Yg dGhlIElFVEYuDQo+ID4NCj4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IERTQ1AgYW5kIG90 aGVyIHBhY2tldCBtYXJraW5ncyBmb3IgUlRDV2ViIFFvUw0KPiA+ICAgICAgICAgQXV0aG9ycyAg ICAgICAgIDogU3ViaGEgRGhlc2lrYW4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEN1 bGxlbiBKZW5uaW5ncw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuIERydXRhDQo+ ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBQYXVsIEpvbmVzDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICBKYW1lcyBQb2xrDQo+ID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvcy0wMi50eHQNCj4gPiAJUGFnZXMgICAgICAgICAgIDogNw0KPiA+ IAlEYXRlICAgICAgICAgICAgOiAyMDE0LTA2LTIzDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAg ICBNYW55IG5ldHdvcmtzLCBzdWNoIGFzIHNlcnZpY2UgcHJvdmlkZXIgYW5kIGVudGVycHJpc2Ug bmV0d29ya3MsIGNhbg0KPiA+ICAgIHByb3ZpZGUgcGVyIHBhY2tldCB0cmVhdG1lbnRzIGJhc2Vk IG9uIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGUNCj4gPiAgICBQb2ludHMgKERTQ1ApIG9u IGEgcGVyLWhvcCBiYXNpcy4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlDQo+ID4gICAgcmVj b21tZW5kZWQgRFNDUCB2YWx1ZXMgZm9yIGJyb3dzZXJzIHRvIHVzZSBmb3IgdmFyaW91cyBjbGFz c2VzIG9mDQo+ID4gICAgdHJhZmZpYy4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLw0KPiA+DQo+ID4gVGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTAyDQo+ID4NCj4g PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4g aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWIt cW9zLTAyDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbg0KPiA+IHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cg0K From nobody Sun Jul 20 18:22:40 2014 Return-Path: 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 C1E441B2A66 for ; Sun, 20 Jul 2014 18:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no 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 oS91EEyU1Nfb for ; Sun, 20 Jul 2014 18:22:36 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D461B2AAF for ; Sun, 20 Jul 2014 18:22:33 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so6808725wes.10 for ; Sun, 20 Jul 2014 18:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=2uca0xtQTSvcVwGuCu2GzTY4S+XwcHnUNg8PVJD8SrI=; b=A5UCdKq4jG/19/WHE3e4cmgKGX0cnChFFuJDZW9zKQpfYYTiDVYWV/+aSgBw7iDBRF pYmA06wrtN17Z5O6qRCbMzxzjp+Va5YWdKo+0Z3ffUDJnQsTTkbdukilg0hCNwu7Vdxw u3qRkMAP5BTRfJBCQwVNaP8dfFCWG0Ux8BbVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=2uca0xtQTSvcVwGuCu2GzTY4S+XwcHnUNg8PVJD8SrI=; b=ICB8CHrFGjpAJ/k3xoQJxELUHRELAuCSz0j+RfMVI3oonkE7EkHkHx+lhtAVRU0aeS yBFrVNpygls/y5nS7F/Dwfm/BPIVevN7JiolYR9WWIx9i+8Cuo3RQNfqT+syOHu+jfFj c5/LA/Tp18jQsKXR1vt/FnGt8XHI3aD8xcVleLA1MgeKn0azkVjnk+tJAunbzguJZKnp EdE2AXzXgx0AWPj9s5eF8Sz9U9szMnjTczhST/M897dkxjyqyO6Quwrarwyp2auDea5t 8VBTCgeIZFMXppwI7o/0nDGZIff3zS9c0B72KLQcp4l+KFEmMkQMiDeIvhtNGsvXtdRV 4Ekw== X-Gm-Message-State: ALoCoQlqvjmaHaeXRMZJL6gx+VIyqQSWJvlWqKyB18BExJIcSvaQ0BjcwtjxaSkGkSi2pu4EUhotmLyYmc0MiEFQ1az5CS6rXQ== X-Received: by 10.180.24.225 with SMTP id x1mr4127258wif.14.1405905752331; Sun, 20 Jul 2014 18:22:32 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeQI8PUdIAZ7WDh+ZR/+qsA== Date: Mon, 21 Jul 2014 03:20:16 +0200 Message-ID: To: "Black, David" , tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/gD4S4UjqC5aloV4VXE4GwsIs0ug Cc: rmcat WG , dart@ietf.org Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:22:37 -0000 Hi, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: 21. juli 2014 02:51 > To: Karen E. Egede Nielsen; tsvwg@ietf.org > Cc: rmcat WG; dart@ietf.org; Black, David > Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt > > Karen, > > , [+dart list] > > > I wonder if the recommendations of this document should not relate to > > the viability (or rather the opposite) of handling different RTCWEB > > data channels individually from a DSCP markings perspective. Or more > > generally relate to the fact that media streams within the same > > congestion control context cannot be handled individually. > > Right now such considerations are not in the document. If the > > intention is for such consideration to come in documents from the dart > > wg, then it would be very important to have a reference to this > > dependency - or ? > > IMHO, such a reference is necessary, although the dart WG draft will be > informational. The reference should be added once there is an official > dart > WG draft (likely to happen this week). > > > Something else: > > > > Right now the document stipulates that packets within the same media > > stream may be marked with different DSCP codepoints, i.e., it is said: > > > > One may select difference drop precedences for the > > different packets in the media flow. Therefore, all packets in the > > stream SHOULD be marked with the same priority but can have > > difference drop precedences. > > > > which indeed is in compliance with the recommendations put forward in > > draft-york-dart-dscp-rtp-00 in that > > it ensures that the DSCP markings do not result in re-ordering > > within the media flow, but has it been ascertained, from a CC > > perspective that usage of different drop precedence within the same CC > > context is viable ? > > Good question - I will include that in my slides for the dart WG meeting. > > > >From the RTCWEB data channel perspective this certainly isn't viable > > >(being > > SCTP based), > > whether it is viable from an RMCAT CC perspective is something that we > > in the RMCAT wg would need to make more clear. > > What's the rationale for "certainly isn't viable" regarding different drop > precedences within a single SCTP session? [Karen] Ok - "certainly not viable" is too strong formulation. Having different drop precedences within the same SCTP CC context would, given that SCTP CC presently is drop driven only, results in that the whole data channel is impacted, from a CC perspective, by the highest drop precedence. But I realize that whether this is acceptable is a question indeed. > > Thanks, > --David (as an editor of draft-york, *not* as a tsvwg WG chair) > > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen E. > > Egede Nielsen > > Sent: Sunday, July 20, 2014 4:49 PM > > To: tsvwg@ietf.org > > Cc: rmcat WG > > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt > > > > Hi, > > > > Please accept the following comments: > > > > I wonder if the recommendations of this document should not relate to > > the viability (or rather the opposite) of handling different RTCWEB > > data channels individually from a DSCP markings perspective. Or more > > generally relate to the fact that media streams within the same > > congestion control context cannot be handled individually. > > Right now such considerations are not in the document. If the > > intention is for such consideration to come in documents from the dart > > wg, then it would be very important to have a reference to this > > dependency - or ? > > > > Something else: > > > > Right now the document stipulates that packets within the same media > > stream may be marked with different DSCP codepoints, i.e., it is said: > > > > One may select difference drop precedences for the > > different packets in the media flow. Therefore, all packets in the > > stream SHOULD be marked with the same priority but can have > > difference drop precedences. > > > > which indeed is in compliance with the recommendations put forward in > > draft-york-dart-dscp-rtp-00 in that > > it ensures that the DSCP markings do not result in re-ordering > > within the media flow, but has it been ascertained, from a CC > > perspective that usage of different drop precedence within the same CC > > context is viable ? > > > > >From the RTCWEB data channel perspective this certainly isn't viable > > >(being > > SCTP based), > > whether it is viable from an RMCAT CC perspective is something that we > > in the RMCAT wg would need to make more clear. > > > > BR, Karen > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > > > drafts@ietf.org > > > Sent: 23. juni 2014 21:12 > > > To: i-d-announce@ietf.org > > > Cc: tsvwg@ietf.org > > > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Transport Area Working Group > > > Working Group of the IETF. > > > > > > Title : DSCP and other packet markings for RTCWeb > > > QoS > > > Authors : Subha Dhesikan > > > Cullen Jennings > > > Dan Druta > > > Paul Jones > > > James Polk > > > Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt > > > Pages : 7 > > > Date : 2014-06-23 > > > > > > Abstract: > > > Many networks, such as service provider and enterprise networks, > > > can > > > provide per packet treatments based on Differentiated Services Code > > > Points (DSCP) on a per-hop basis. This document provides the > > > recommended DSCP values for browsers to use for various classes of > > > traffic. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 20 19:00:48 2014 Return-Path: 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 7950B1B2ACD; Sun, 20 Jul 2014 19:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 vhepvacBtDEZ; Sun, 20 Jul 2014 19:00:38 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87B11B2ABE; Sun, 20 Jul 2014 19:00:38 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L20ZD3026482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 22:00:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6L20ZD3026482 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405908036; bh=8Y2vgoH3+QCRJ+gE/BAbliv8Szw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ElZeyQ1KlcqfGe230DeYSlIV3YXM1RKMrjwfl0X8fKeCirt7QoEclmzNhYs3IXaut wR4j3A/Cl5AAx19w4PXVFvPjzwWL+oXDOwvnABXV9ydFgUNaIjGf9J51T7xhrLQwZm 54RAQ9t1Y+8q0eqeuzOuuKF4eNzIxM6+kxE3SXss= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6L20ZD3026482 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Sun, 20 Jul 2014 22:00:30 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6L20Tud015443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jul 2014 22:00:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Sun, 20 Jul 2014 22:00:29 -0400 From: "Black, David" To: "Karen E. Egede Nielsen" , "tsvwg@ietf.org" Date: Sun, 20 Jul 2014 22:00:28 -0400 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt Thread-Index: AQLxFDM79VKa65qAlrEeSSnrsrTmeQI8PUdIAZ7WDh+ZR/+qsIAAC7Xw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/RbYpoWMyc6hxY_qqfPcZjwBAekE Cc: rmcat WG , "Black, David" , "dart@ietf.org" Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 02:00:41 -0000 S2FyZW4sDQoNCj4gPiBXaGF0J3MgdGhlIHJhdGlvbmFsZSBmb3IgImNlcnRhaW5seSBpc24ndCB2 aWFibGUiIHJlZ2FyZGluZyBkaWZmZXJlbnQgZHJvcA0KPiA+IHByZWNlZGVuY2VzIHdpdGhpbiBh IHNpbmdsZSBTQ1RQIHNlc3Npb24/DQo+DQo+IFtLYXJlbl0gT2sgLSAiY2VydGFpbmx5IG5vdCB2 aWFibGUiIGlzIHRvbyBzdHJvbmcgZm9ybXVsYXRpb24uDQo+IEhhdmluZyBkaWZmZXJlbnQgZHJv cCBwcmVjZWRlbmNlcyB3aXRoaW4gdGhlIHNhbWUgU0NUUCBDQyBjb250ZXh0IHdvdWxkLA0KPiBn aXZlbiB0aGF0IFNDVFAgQ0MgcHJlc2VudGx5IGlzIGRyb3AgZHJpdmVuIG9ubHksDQo+IHJlc3Vs dHMgaW4gdGhhdCB0aGUgd2hvbGUgZGF0YSBjaGFubmVsIGlzIGltcGFjdGVkLCBmcm9tIGEgQ0Mg cGVyc3BlY3RpdmUsDQo+IGJ5IHRoZSBoaWdoZXN0IGRyb3AgcHJlY2VkZW5jZS4gQnV0IEkgcmVh bGl6ZSB0aGF0IHdoZXRoZXIgdGhpcyBpcw0KPiBhY2NlcHRhYmxlIGlzIGEgcXVlc3Rpb24gaW5k ZWVkLg0KDQpJIHRoaW5rIHlvdSdyZSBvbiB0byBzb21ldGhpbmcgaGVyZS4gIElmIHRoZSBkcm9w IHByZWNlZGVuY2VzIG9ubHkgY2FtZSBpbnRvDQpwbGF5IGFmdGVyIHRoZSBkZWNpc2lvbiB0byBk cm9wIGEgcGFja2V0IGhhZCBiZWVuIG1hZGUsIHRoZWlyIGVmZmVjdCB3b3VsZA0KcHJvYmFibHkg YmUgbWluaW1hbCwgYXMgdGhleSB3b3VsZCBvbmx5IGFmZmVjdCB3aGF0IHRvIGRyb3AgaW4gYSBz ZXNzaW9uLCBub3QNCmhvdyBtdWNoIHRvIGRyb3AuICBPVE9ILCBEaWZmU2VydiBBRiBpcyBub3Qg aW50ZW5kZWQgdG8gb3BlcmF0ZSBpbiB0aGF0IGZhc2hpb24NCi0gdGhlIHJhdGlvbmFsZSBmb3Ig dGhlIDMgZHJvcCBwcmVjZWRlbmNlcyBwZXIgQUYgY2xhc3Mgd2FzIGJhc2VkIG9uIGVudmlzaW9u aW5nDQp0aGUgb3V0cHV0IG9mIHR3by10aHJlc2hvbGQgcmF0ZSBzaGFwZXI6DQoJQUZ4MSAtIFdp dGhpbiBiYXNlIG9yIGNvbW1pdHRlZCB0cmFmZmljIHByb2ZpbGUNCglBRngyIC0gQmV5b25kIGJh c2UvY29tbWl0dGVkLCBidXQgd2l0aGluIGV4Y2VzcyBvciBidXJzdCB0cmFmZmljIHByb2ZpbGUN CglBRngzIC0gQ29tcGxldGVseSBvdXQgb2YgcHJvZmlsZQ0KDQpIZW5jZSB0aGUgcmVsYXRpdmUg bWl4IG9mIHRob3NlIGRyb3AgcHJlY2VkZW5jZXMgY2FuIGJlIGV4cGVjdGVkIHRvIGFmZmVjdA0K dGhlIG92ZXJhbGwgZHJvcCByYXRlL3Byb2JhYmlsaXR5IHNlZW4gaW4gYSBzZXNzaW9uIHdoZXJl IHRob3NlIHByZWNlZGVuY2VzDQphcmUgbWl4ZWQuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXJlbiBFLiBFZ2VkZSBOaWVsc2Vu IFttYWlsdG86a2FyZW4ubmllbHNlbkB0aWV0by5jb21dDQo+IFNlbnQ6IFN1bmRheSwgSnVseSAy MCwgMjAxNCA5OjIwIFBNDQo+IFRvOiBCbGFjaywgRGF2aWQ7IHRzdndnQGlldGYub3JnDQo+IENj OiBybWNhdCBXRzsgZGFydEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3RzdndnXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMDIudHh0DQo+IA0KPiBIaSwNCj4gDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBCbGFjaywgRGF2aWQgW21h aWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KPiA+IFNlbnQ6IDIxLiBqdWxpIDIwMTQgMDI6NTEN Cj4gPiBUbzogS2FyZW4gRS4gRWdlZGUgTmllbHNlbjsgdHN2d2dAaWV0Zi5vcmcNCj4gPiBDYzog cm1jYXQgV0c7IGRhcnRAaWV0Zi5vcmc7IEJsYWNrLCBEYXZpZA0KPiA+IFN1YmplY3Q6IFJFOiBb dHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0wMi50eHQNCj4g Pg0KPiA+IEthcmVuLA0KPiA+DQo+ID4gPFdHIGNoYWlyIGhhdCBvZmY+LCBbK2RhcnQgbGlzdF0N Cj4gPg0KPiA+ID4gSSB3b25kZXIgaWYgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIGRvY3Vt ZW50IHNob3VsZCBub3QgcmVsYXRlIHRvDQo+ID4gPiB0aGUgdmlhYmlsaXR5IChvciByYXRoZXIg dGhlIG9wcG9zaXRlKSBvZiBoYW5kbGluZyBkaWZmZXJlbnQgUlRDV0VCDQo+ID4gPiBkYXRhIGNo YW5uZWxzIGluZGl2aWR1YWxseSBmcm9tIGEgRFNDUCBtYXJraW5ncyBwZXJzcGVjdGl2ZS4gT3Ig bW9yZQ0KPiA+ID4gZ2VuZXJhbGx5IHJlbGF0ZSB0byB0aGUgZmFjdCB0aGF0IG1lZGlhIHN0cmVh bXMgd2l0aGluIHRoZSBzYW1lDQo+ID4gPiBjb25nZXN0aW9uIGNvbnRyb2wgY29udGV4dCBjYW5u b3QgYmUgaGFuZGxlZCBpbmRpdmlkdWFsbHkuDQo+ID4gPiBSaWdodCBub3cgc3VjaCBjb25zaWRl cmF0aW9ucyBhcmUgbm90IGluIHRoZSBkb2N1bWVudC4gSWYgdGhlDQo+ID4gPiBpbnRlbnRpb24g aXMgZm9yIHN1Y2ggY29uc2lkZXJhdGlvbiB0byBjb21lIGluIGRvY3VtZW50cyBmcm9tIHRoZSBk YXJ0DQo+ID4gPiB3ZywgdGhlbiBpdCB3b3VsZCBiZSB2ZXJ5IGltcG9ydGFudCB0byAgaGF2ZSBh IHJlZmVyZW5jZSB0byB0aGlzDQo+ID4gPiBkZXBlbmRlbmN5IC0gb3IgPw0KPiA+DQo+ID4gSU1I Tywgc3VjaCBhIHJlZmVyZW5jZSBpcyBuZWNlc3NhcnksIGFsdGhvdWdoIHRoZSBkYXJ0IFdHIGRy YWZ0IHdpbGwgYmUNCj4gPiBpbmZvcm1hdGlvbmFsLiAgVGhlIHJlZmVyZW5jZSBzaG91bGQgYmUg YWRkZWQgb25jZSB0aGVyZSBpcyBhbiBvZmZpY2lhbA0KPiA+IGRhcnQNCj4gPiBXRyBkcmFmdCAo bGlrZWx5IHRvIGhhcHBlbiB0aGlzIHdlZWspLg0KPiA+DQo+ID4gPiBTb21ldGhpbmcgZWxzZToN Cj4gPiA+DQo+ID4gPiBSaWdodCBub3cgdGhlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCBwYWNr ZXRzIHdpdGhpbiB0aGUgc2FtZSBtZWRpYQ0KPiA+ID4gc3RyZWFtIG1heSBiZSBtYXJrZWQgd2l0 aCBkaWZmZXJlbnQgRFNDUCBjb2RlcG9pbnRzLCBpLmUuLCBpdCBpcyBzYWlkOg0KPiA+ID4NCj4g PiA+ICAgIE9uZSBtYXkgc2VsZWN0IGRpZmZlcmVuY2UgZHJvcCBwcmVjZWRlbmNlcyBmb3IgdGhl DQo+ID4gPiAgICBkaWZmZXJlbnQgcGFja2V0cyBpbiB0aGUgbWVkaWEgZmxvdy4gIFRoZXJlZm9y ZSwgYWxsIHBhY2tldHMgaW4gdGhlDQo+ID4gPiAgICBzdHJlYW0gU0hPVUxEIGJlIG1hcmtlZCB3 aXRoIHRoZSBzYW1lIHByaW9yaXR5IGJ1dCBjYW4gaGF2ZQ0KPiA+ID4gICAgZGlmZmVyZW5jZSBk cm9wIHByZWNlZGVuY2VzLg0KPiA+ID4NCj4gPiA+IHdoaWNoIGluZGVlZCBpcyBpbiBjb21wbGlh bmNlIHdpdGggdGhlIHJlY29tbWVuZGF0aW9ucyBwdXQgZm9yd2FyZCBpbg0KPiA+ID4gZHJhZnQt eW9yay1kYXJ0LWRzY3AtcnRwLTAwIGluIHRoYXQNCj4gPiA+IGl0IGVuc3VyZXMgdGhhdCB0aGUg RFNDUCBtYXJraW5ncyAgZG8gbm90IHJlc3VsdCBpbiByZS1vcmRlcmluZw0KPiA+ID4gd2l0aGlu IHRoZSBtZWRpYSBmbG93LCBidXQgaGFzIGl0IGJlZW4gYXNjZXJ0YWluZWQsIGZyb20gYSBDQw0K PiA+ID4gcGVyc3BlY3RpdmUgdGhhdCB1c2FnZSBvZiBkaWZmZXJlbnQgZHJvcCBwcmVjZWRlbmNl IHdpdGhpbiB0aGUgc2FtZSBDQw0KPiA+ID4gY29udGV4dCBpcyB2aWFibGUgPw0KPiA+DQo+ID4g R29vZCBxdWVzdGlvbiAtIEkgd2lsbCBpbmNsdWRlIHRoYXQgaW4gbXkgc2xpZGVzIGZvciB0aGUg ZGFydCBXRyBtZWV0aW5nLg0KPiA+DQo+ID4gPiA+RnJvbSB0aGUgUlRDV0VCIGRhdGEgY2hhbm5l bCBwZXJzcGVjdGl2ZSB0aGlzIGNlcnRhaW5seSBpc24ndCB2aWFibGUNCj4gPiA+ID4oYmVpbmcN Cj4gPiA+IFNDVFAgYmFzZWQpLA0KPiA+ID4gd2hldGhlciBpdCBpcyB2aWFibGUgZnJvbSBhbiBS TUNBVCBDQyBwZXJzcGVjdGl2ZSBpcyBzb21ldGhpbmcgdGhhdCB3ZQ0KPiA+ID4gaW4gdGhlIFJN Q0FUIHdnIHdvdWxkIG5lZWQgdG8gbWFrZSBtb3JlIGNsZWFyLg0KPiA+DQo+ID4gV2hhdCdzIHRo ZSByYXRpb25hbGUgZm9yICJjZXJ0YWlubHkgaXNuJ3QgdmlhYmxlIiByZWdhcmRpbmcgZGlmZmVy ZW50IGRyb3ANCj4gPiBwcmVjZWRlbmNlcyB3aXRoaW4gYSBzaW5nbGUgU0NUUCBzZXNzaW9uPw0K PiBbS2FyZW5dIE9rIC0gImNlcnRhaW5seSBub3QgdmlhYmxlIiBpcyB0b28gc3Ryb25nIGZvcm11 bGF0aW9uLg0KPiBIYXZpbmcgZGlmZmVyZW50IGRyb3AgcHJlY2VkZW5jZXMgd2l0aGluIHRoZSBz YW1lIFNDVFAgQ0MgY29udGV4dCB3b3VsZCwNCj4gZ2l2ZW4gdGhhdCBTQ1RQIENDIHByZXNlbnRs eSBpcyBkcm9wIGRyaXZlbiBvbmx5LA0KPiByZXN1bHRzIGluIHRoYXQgdGhlIHdob2xlIGRhdGEg Y2hhbm5lbCBpcyBpbXBhY3RlZCwgZnJvbSBhIENDIHBlcnNwZWN0aXZlLA0KPiBieSB0aGUgaGln aGVzdCBkcm9wIHByZWNlZGVuY2UuIEJ1dCBJIHJlYWxpemUgdGhhdCB3aGV0aGVyIHRoaXMgaXMN Cj4gYWNjZXB0YWJsZSBpcyBhIHF1ZXN0aW9uIGluZGVlZC4NCj4gDQo+ID4NCj4gPiBUaGFua3Ms DQo+ID4gLS1EYXZpZCAoYXMgYW4gZWRpdG9yIG9mIGRyYWZ0LXlvcmssICpub3QqIGFzIGEgdHN2 d2cgV0cgY2hhaXIpDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBLYXJlbiBFLg0KPiA+ID4gRWdlZGUgTmllbHNlbg0KPiA+ID4gU2VudDogU3VuZGF5LCBKdWx5 IDIwLCAyMDE0IDQ6NDkgUE0NCj4gPiA+IFRvOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+ID4gQ2M6IHJt Y2F0IFdHDQo+ID4gPiBTdWJqZWN0OiBSZTogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXRzdndnLXJ0Y3dlYi1xb3MtMDIudHh0DQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4g UGxlYXNlIGFjY2VwdCB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KPiA+ID4NCj4gPiA+IEkgd29u ZGVyIGlmIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBzaG91bGQgbm90IHJl bGF0ZSB0bw0KPiA+ID4gdGhlIHZpYWJpbGl0eSAob3IgcmF0aGVyIHRoZSBvcHBvc2l0ZSkgb2Yg aGFuZGxpbmcgZGlmZmVyZW50IFJUQ1dFQg0KPiA+ID4gZGF0YSBjaGFubmVscyBpbmRpdmlkdWFs bHkgZnJvbSBhIERTQ1AgbWFya2luZ3MgcGVyc3BlY3RpdmUuIE9yIG1vcmUNCj4gPiA+IGdlbmVy YWxseSByZWxhdGUgdG8gdGhlIGZhY3QgdGhhdCBtZWRpYSBzdHJlYW1zIHdpdGhpbiB0aGUgc2Ft ZQ0KPiA+ID4gY29uZ2VzdGlvbiBjb250cm9sIGNvbnRleHQgY2Fubm90IGJlIGhhbmRsZWQgaW5k aXZpZHVhbGx5Lg0KPiA+ID4gUmlnaHQgbm93IHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBp biB0aGUgZG9jdW1lbnQuIElmIHRoZQ0KPiA+ID4gaW50ZW50aW9uIGlzIGZvciBzdWNoIGNvbnNp ZGVyYXRpb24gdG8gY29tZSBpbiBkb2N1bWVudHMgZnJvbSB0aGUgZGFydA0KPiA+ID4gd2csIHRo ZW4gaXQgd291bGQgYmUgdmVyeSBpbXBvcnRhbnQgdG8gIGhhdmUgYSByZWZlcmVuY2UgdG8gdGhp cw0KPiA+ID4gZGVwZW5kZW5jeSAtIG9yID8NCj4gPiA+DQo+ID4gPiBTb21ldGhpbmcgZWxzZToN Cj4gPiA+DQo+ID4gPiBSaWdodCBub3cgdGhlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCBwYWNr ZXRzIHdpdGhpbiB0aGUgc2FtZSBtZWRpYQ0KPiA+ID4gc3RyZWFtIG1heSBiZSBtYXJrZWQgd2l0 aCBkaWZmZXJlbnQgRFNDUCBjb2RlcG9pbnRzLCBpLmUuLCBpdCBpcyBzYWlkOg0KPiA+ID4NCj4g PiA+ICAgIE9uZSBtYXkgc2VsZWN0IGRpZmZlcmVuY2UgZHJvcCBwcmVjZWRlbmNlcyBmb3IgdGhl DQo+ID4gPiAgICBkaWZmZXJlbnQgcGFja2V0cyBpbiB0aGUgbWVkaWEgZmxvdy4gIFRoZXJlZm9y ZSwgYWxsIHBhY2tldHMgaW4gdGhlDQo+ID4gPiAgICBzdHJlYW0gU0hPVUxEIGJlIG1hcmtlZCB3 aXRoIHRoZSBzYW1lIHByaW9yaXR5IGJ1dCBjYW4gaGF2ZQ0KPiA+ID4gICAgZGlmZmVyZW5jZSBk cm9wIHByZWNlZGVuY2VzLg0KPiA+ID4NCj4gPiA+IHdoaWNoIGluZGVlZCBpcyBpbiBjb21wbGlh bmNlIHdpdGggdGhlIHJlY29tbWVuZGF0aW9ucyBwdXQgZm9yd2FyZCBpbg0KPiA+ID4gZHJhZnQt eW9yay1kYXJ0LWRzY3AtcnRwLTAwIGluIHRoYXQNCj4gPiA+IGl0IGVuc3VyZXMgdGhhdCB0aGUg RFNDUCBtYXJraW5ncyAgZG8gbm90IHJlc3VsdCBpbiByZS1vcmRlcmluZw0KPiA+ID4gd2l0aGlu IHRoZSBtZWRpYSBmbG93LCBidXQgaGFzIGl0IGJlZW4gYXNjZXJ0YWluZWQsIGZyb20gYSBDQw0K PiA+ID4gcGVyc3BlY3RpdmUgdGhhdCB1c2FnZSBvZiBkaWZmZXJlbnQgZHJvcCBwcmVjZWRlbmNl IHdpdGhpbiB0aGUgc2FtZSBDQw0KPiA+ID4gY29udGV4dCBpcyB2aWFibGUgPw0KPiA+ID4NCj4g PiA+ID5Gcm9tIHRoZSBSVENXRUIgZGF0YSBjaGFubmVsIHBlcnNwZWN0aXZlIHRoaXMgY2VydGFp bmx5IGlzbid0IHZpYWJsZQ0KPiA+ID4gPihiZWluZw0KPiA+ID4gU0NUUCBiYXNlZCksDQo+ID4g PiB3aGV0aGVyIGl0IGlzIHZpYWJsZSBmcm9tIGFuIFJNQ0FUIENDIHBlcnNwZWN0aXZlIGlzIHNv bWV0aGluZyB0aGF0IHdlDQo+ID4gPiBpbiB0aGUgUk1DQVQgd2cgd291bGQgbmVlZCB0byBtYWtl IG1vcmUgY2xlYXIuDQo+ID4gPg0KPiA+ID4gQlIsIEthcmVuDQo+ID4gPg0KPiA+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC0NCj4gPiA+ID4gZHJhZnRz QGlldGYub3JnDQo+ID4gPiA+IFNlbnQ6IDIzLiBqdW5pIDIwMTQgMjE6MTINCj4gPiA+ID4gVG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+ID4gPiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gPiA+ ID4gU3ViamVjdDogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1x b3MtMDIudHh0DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiA+ID4gPiBk aXJlY3Rvcmllcy4NCj4gPiA+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRy YW5zcG9ydCBBcmVhIFdvcmtpbmcgR3JvdXANCj4gPiA+ID4gV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEU0NQIGFu ZCBvdGhlciBwYWNrZXQgbWFya2luZ3MgZm9yIFJUQ1dlYg0KPiA+ID4gPiBRb1MNCj4gPiA+ID4g ICAgICAgICBBdXRob3JzICAgICAgICAgOiBTdWJoYSBEaGVzaWthbg0KPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgICAgICAgIEN1bGxlbiBKZW5uaW5ncw0KPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIERhbiBEcnV0YQ0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg IFBhdWwgSm9uZXMNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBKYW1lcyBQb2xr DQo+ID4gPiA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mt MDIudHh0DQo+ID4gPiA+IAlQYWdlcyAgICAgICAgICAgOiA3DQo+ID4gPiA+IAlEYXRlICAgICAg ICAgICAgOiAyMDE0LTA2LTIzDQo+ID4gPiA+DQo+ID4gPiA+IEFic3RyYWN0Og0KPiA+ID4gPiAg ICBNYW55IG5ldHdvcmtzLCBzdWNoIGFzIHNlcnZpY2UgcHJvdmlkZXIgYW5kIGVudGVycHJpc2Ug bmV0d29ya3MsDQo+ID4gPiA+IGNhbg0KPiA+ID4gPiAgICBwcm92aWRlIHBlciBwYWNrZXQgdHJl YXRtZW50cyBiYXNlZCBvbiBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBDb2RlDQo+ID4gPiA+ICAg IFBvaW50cyAoRFNDUCkgb24gYSBwZXItaG9wIGJhc2lzLiAgVGhpcyBkb2N1bWVudCBwcm92aWRl cyB0aGUNCj4gPiA+ID4gICAgcmVjb21tZW5kZWQgRFNDUCB2YWx1ZXMgZm9yIGJyb3dzZXJzIHRv IHVzZSBmb3IgdmFyaW91cyBjbGFzc2VzIG9mDQo+ID4gPiA+ICAgIHRyYWZmaWMuDQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOg0KPiA+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MvDQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiA+ID4gPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMDINCj4gPiA+ID4NCj4g PiA+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiA+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRzdndn LXJ0Y3dlYi1xb3MtMDINCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiA+ ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0DQo+ID4gPiA+IHRvb2xzLmlldGYub3JnLg0KPiA+ID4gPg0KPiA+ID4gPiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4g PiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo= From nobody Mon Jul 21 04:08:55 2014 Return-Path: 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 71DA01B2B8D; Mon, 21 Jul 2014 04:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 xJyskRcg4oMG; Mon, 21 Jul 2014 04:08:44 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FF61B2D7A; Mon, 21 Jul 2014 04:08:42 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so3833565wib.4 for ; Mon, 21 Jul 2014 04:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pLkTQD094eHAhomXeoG/pby02ikZqHfmtvVX0wT4PDs=; b=AGRdiqrb/cpqmyTXbRGdU1oIaU5gs+2+PgT1FrUMaVbzaGBMC30jjivBRfNflrJuXF ji7Dh2v7tgr9uLvyEmHl2TFxFEP0NZJJ0IhM9CnnXxdY9dpGEOVBLid5QyKUZbOvLX0c gXoBd/rqE7dXib67ztdLiB57ibmw6hIyFpshVLKqohqyyj9vAUq8iFDw0zuPLIy+Cu9w MdEfZHW5Vpa7tASERSP4/G3UwxJR+uYd5btNDcGUgLkCqOHhEpXWk3BmFDWQqQVTsWen mQF1M3UmXQoXPCa4x6zQ01VmYsK1KITPgO/GH5EYndVXlUH0iwdSpZRwMuNfJQl69y5r JeDA== X-Received: by 10.194.48.103 with SMTP id k7mr21719127wjn.68.1405940919969; Mon, 21 Jul 2014 04:08:39 -0700 (PDT) Received: from [31.133.140.161] (dhcp-8ca1.meeting.ietf.org. [31.133.140.161]) by mx.google.com with ESMTPSA id lk7sm36836510wjb.24.2014.07.21.04.08.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 04:08:39 -0700 (PDT) Message-ID: <53CCF4B1.6030004@gmail.com> Date: Mon, 21 Jul 2014 23:08:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Black, David" References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/ri-yV2RH4BY446Cs8tSPE_p7dO0 Cc: "Karen E. Egede Nielsen" , rmcat WG , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 11:08:47 -0000 On 21/07/2014 14:00, Black, David wrote: > Karen, > >>> What's the rationale for "certainly isn't viable" regarding different drop >>> precedences within a single SCTP session? >> [Karen] Ok - "certainly not viable" is too strong formulation. >> Having different drop precedences within the same SCTP CC context would, >> given that SCTP CC presently is drop driven only, >> results in that the whole data channel is impacted, from a CC perspective, >> by the highest drop precedence. But I realize that whether this is >> acceptable is a question indeed. > > I think you're on to something here. If the drop precedences only came into > play after the decision to drop a packet had been made, their effect would > probably be minimal, as they would only affect what to drop in a session, not > how much to drop. OTOH, DiffServ AF is not intended to operate in that fashion > - the rationale for the 3 drop precedences per AF class was based on envisioning > the output of two-threshold rate shaper: > AFx1 - Within base or committed traffic profile > AFx2 - Beyond base/committed, but within excess or burst traffic profile > AFx3 - Completely out of profile > > Hence the relative mix of those drop precedences can be expected to affect > the overall drop rate/probability seen in a session where those precedences > are mixed. Yes. And it was clearly aimed at layered video, such that there was a benefit to the end user in dropping the least important layer during lossy periods. With anything like a TCP-like congestion control algorithm in sight, the effects may be completely bizarre. Brian > > Thanks, > --David > >> -----Original Message----- >> From: Karen E. Egede Nielsen [mailto:karen.nielsen@tieto.com] >> Sent: Sunday, July 20, 2014 9:20 PM >> To: Black, David; tsvwg@ietf.org >> Cc: rmcat WG; dart@ietf.org >> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >> >> Hi, >> >>> -----Original Message----- >>> From: Black, David [mailto:david.black@emc.com] >>> Sent: 21. juli 2014 02:51 >>> To: Karen E. Egede Nielsen; tsvwg@ietf.org >>> Cc: rmcat WG; dart@ietf.org; Black, David >>> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >>> >>> Karen, >>> >>> , [+dart list] >>> >>>> I wonder if the recommendations of this document should not relate to >>>> the viability (or rather the opposite) of handling different RTCWEB >>>> data channels individually from a DSCP markings perspective. Or more >>>> generally relate to the fact that media streams within the same >>>> congestion control context cannot be handled individually. >>>> Right now such considerations are not in the document. If the >>>> intention is for such consideration to come in documents from the dart >>>> wg, then it would be very important to have a reference to this >>>> dependency - or ? >>> IMHO, such a reference is necessary, although the dart WG draft will be >>> informational. The reference should be added once there is an official >>> dart >>> WG draft (likely to happen this week). >>> >>>> Something else: >>>> >>>> Right now the document stipulates that packets within the same media >>>> stream may be marked with different DSCP codepoints, i.e., it is said: >>>> >>>> One may select difference drop precedences for the >>>> different packets in the media flow. Therefore, all packets in the >>>> stream SHOULD be marked with the same priority but can have >>>> difference drop precedences. >>>> >>>> which indeed is in compliance with the recommendations put forward in >>>> draft-york-dart-dscp-rtp-00 in that >>>> it ensures that the DSCP markings do not result in re-ordering >>>> within the media flow, but has it been ascertained, from a CC >>>> perspective that usage of different drop precedence within the same CC >>>> context is viable ? >>> Good question - I will include that in my slides for the dart WG meeting. >>> >>>> >From the RTCWEB data channel perspective this certainly isn't viable >>>>> (being >>>> SCTP based), >>>> whether it is viable from an RMCAT CC perspective is something that we >>>> in the RMCAT wg would need to make more clear. >>> What's the rationale for "certainly isn't viable" regarding different drop >>> precedences within a single SCTP session? >> [Karen] Ok - "certainly not viable" is too strong formulation. >> Having different drop precedences within the same SCTP CC context would, >> given that SCTP CC presently is drop driven only, >> results in that the whole data channel is impacted, from a CC perspective, >> by the highest drop precedence. But I realize that whether this is >> acceptable is a question indeed. >> >>> Thanks, >>> --David (as an editor of draft-york, *not* as a tsvwg WG chair) >>> >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen E. >>>> Egede Nielsen >>>> Sent: Sunday, July 20, 2014 4:49 PM >>>> To: tsvwg@ietf.org >>>> Cc: rmcat WG >>>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >>>> >>>> Hi, >>>> >>>> Please accept the following comments: >>>> >>>> I wonder if the recommendations of this document should not relate to >>>> the viability (or rather the opposite) of handling different RTCWEB >>>> data channels individually from a DSCP markings perspective. Or more >>>> generally relate to the fact that media streams within the same >>>> congestion control context cannot be handled individually. >>>> Right now such considerations are not in the document. If the >>>> intention is for such consideration to come in documents from the dart >>>> wg, then it would be very important to have a reference to this >>>> dependency - or ? >>>> >>>> Something else: >>>> >>>> Right now the document stipulates that packets within the same media >>>> stream may be marked with different DSCP codepoints, i.e., it is said: >>>> >>>> One may select difference drop precedences for the >>>> different packets in the media flow. Therefore, all packets in the >>>> stream SHOULD be marked with the same priority but can have >>>> difference drop precedences. >>>> >>>> which indeed is in compliance with the recommendations put forward in >>>> draft-york-dart-dscp-rtp-00 in that >>>> it ensures that the DSCP markings do not result in re-ordering >>>> within the media flow, but has it been ascertained, from a CC >>>> perspective that usage of different drop precedence within the same CC >>>> context is viable ? >>>> >>>> >From the RTCWEB data channel perspective this certainly isn't viable >>>>> (being >>>> SCTP based), >>>> whether it is viable from an RMCAT CC perspective is something that we >>>> in the RMCAT wg would need to make more clear. >>>> >>>> BR, Karen >>>> >>>>> -----Original Message----- >>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- >>>>> drafts@ietf.org >>>>> Sent: 23. juni 2014 21:12 >>>>> To: i-d-announce@ietf.org >>>>> Cc: tsvwg@ietf.org >>>>> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Transport Area Working Group >>>>> Working Group of the IETF. >>>>> >>>>> Title : DSCP and other packet markings for RTCWeb >>>>> QoS >>>>> Authors : Subha Dhesikan >>>>> Cullen Jennings >>>>> Dan Druta >>>>> Paul Jones >>>>> James Polk >>>>> Filename : draft-ietf-tsvwg-rtcweb-qos-02.txt >>>>> Pages : 7 >>>>> Date : 2014-06-23 >>>>> >>>>> Abstract: >>>>> Many networks, such as service provider and enterprise networks, >>>>> can >>>>> provide per packet treatments based on Differentiated Services Code >>>>> Points (DSCP) on a per-hop basis. This document provides the >>>>> recommended DSCP values for browsers to use for various classes of >>>>> traffic. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 05:14:18 2014 Return-Path: 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 612C91B2D4A; Mon, 21 Jul 2014 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6z9yxx9ClsHv; Mon, 21 Jul 2014 05:13:39 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A2A1B2884; Mon, 21 Jul 2014 05:13:38 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X9CTI-0003KY-9v; Mon, 21 Jul 2014 14:13:36 +0200 Received: from dhcp-8bda.meeting.ietf.org ([31.133.139.218]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X9CTH-00040B-LZ; Mon, 21 Jul 2014 14:13:36 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <53CCF4B1.6030004@gmail.com> Date: Mon, 21 Jul 2014 14:13:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> <53CCF4B1.6030004@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 12 sum msgs/h 5 total rcpts 18561 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6024BC657B88BEF5A70F9DE2D49E9E0F5F1A2150 X-UiO-SPAM-Test: remote_host: 31.133.139.218 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 37 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/_Gn4NREFOoQtAaJ5v7TEuT0IDvo Cc: "Karen E. Egede Nielsen" , rmcat WG , "Black, David" , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 12:14:02 -0000 On 21. juli 2014, at 13:08, Brian E Carpenter = wrote: > On 21/07/2014 14:00, Black, David wrote: >> Karen, >>=20 >>>> What's the rationale for "certainly isn't viable" regarding = different drop >>>> precedences within a single SCTP session? >>> [Karen] Ok - "certainly not viable" is too strong formulation. >>> Having different drop precedences within the same SCTP CC context = would, >>> given that SCTP CC presently is drop driven only, >>> results in that the whole data channel is impacted, from a CC = perspective, >>> by the highest drop precedence. But I realize that whether this is >>> acceptable is a question indeed. >>=20 >> I think you're on to something here. If the drop precedences only = came into >> play after the decision to drop a packet had been made, their effect = would >> probably be minimal, as they would only affect what to drop in a = session, not >> how much to drop. OTOH, DiffServ AF is not intended to operate in = that fashion >> - the rationale for the 3 drop precedences per AF class was based on = envisioning >> the output of two-threshold rate shaper: >> AFx1 - Within base or committed traffic profile >> AFx2 - Beyond base/committed, but within excess or burst traffic = profile >> AFx3 - Completely out of profile >>=20 >> Hence the relative mix of those drop precedences can be expected to = affect >> the overall drop rate/probability seen in a session where those = precedences >> are mixed. >=20 > Yes. And it was clearly aimed at layered video, such that there was > a benefit to the end user in dropping the least important layer > during lossy periods. With anything like a TCP-like congestion > control algorithm in sight, the effects may be completely bizarre. Reordering could make this even worse. Could different drop precedences = cause reordering? Cheers, Michael From nobody Mon Jul 21 06:02:53 2014 Return-Path: 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 D5CCF1B2946; Mon, 21 Jul 2014 06:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 wg5zoM07g8SA; Mon, 21 Jul 2014 06:02:44 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072721B2BC1; Mon, 21 Jul 2014 06:02:40 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6LD2ai5007565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 09:02:37 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s6LD2ai5007565 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1405947758; bh=24HeUWi1xnoe1yrrz34OJ548KIk=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SVmsml5QfwXNMs+RagKsrHLUOIX0b/Chv5HnxTdzmbNCavHNjLR+8sXMRiN+clRND j1kuXHxoV7aCmCpLOm1D0r8FFYEBQy3uyv4Yt6Y69wDVYORhDOAcji4h1if9qeiSt5 H8uqIgpXfUH9sRl4j39DQ6bHgjnZpLiKfQvNSZzA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s6LD2ai5007565 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 21 Jul 2014 09:02:20 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6LD2JuI005897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 09:02:19 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Mon, 21 Jul 2014 09:02:19 -0400 From: "Black, David" To: Michael Welzl , Brian E Carpenter Date: Mon, 21 Jul 2014 09:02:17 -0400 Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt Thread-Index: Ac+k3TTr8iUPhOT8Qg+6sRLudWbtEAABnElQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71207783F6420@MX15A.corp.emc.com> References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com> <53CCF4B1.6030004@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/BpmEK-Rzr7ZWG8y5_xhpaS5NQ_s Cc: "Karen E. Egede Nielsen" , rmcat WG , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rmcat] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:02:48 -0000 > >> Hence the relative mix of those drop precedences can be expected to af= fect > >> the overall drop rate/probability seen in a session where those preced= ences > >> are mixed. > > > > Yes. And it was clearly aimed at layered video, such that there was > > a benefit to the end user in dropping the least important layer > > during lossy periods. With anything like a TCP-like congestion > > control algorithm in sight, the effects may be completely bizarre. >=20 > Reordering could make this even worse. Could different drop precedences c= ause > reordering? No, packets MUST NOT be reordered among the three drop precedences within an AF class (e.g., AF2x). See RFC 2597 and draft-york. Thanks, --David > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Monday, July 21, 2014 8:14 AM > To: Brian E Carpenter > Cc: Black, David; Karen E. Egede Nielsen; rmcat WG; dart@ietf.org; > tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt >=20 >=20 > On 21. juli 2014, at 13:08, Brian E Carpenter > wrote: >=20 > > On 21/07/2014 14:00, Black, David wrote: > >> Karen, > >> > >>>> What's the rationale for "certainly isn't viable" regarding differen= t > drop > >>>> precedences within a single SCTP session? > >>> [Karen] Ok - "certainly not viable" is too strong formulation. > >>> Having different drop precedences within the same SCTP CC context wou= ld, > >>> given that SCTP CC presently is drop driven only, > >>> results in that the whole data channel is impacted, from a CC perspec= tive, > >>> by the highest drop precedence. But I realize that whether this is > >>> acceptable is a question indeed. > >> > >> I think you're on to something here. If the drop precedences only cam= e > into > >> play after the decision to drop a packet had been made, their effect w= ould > >> probably be minimal, as they would only affect what to drop in a sessi= on, > not > >> how much to drop. OTOH, DiffServ AF is not intended to operate in tha= t > fashion > >> - the rationale for the 3 drop precedences per AF class was based on > envisioning > >> the output of two-threshold rate shaper: > >> AFx1 - Within base or committed traffic profile > >> AFx2 - Beyond base/committed, but within excess or burst traffic prof= ile > >> AFx3 - Completely out of profile > >> > >> Hence the relative mix of those drop precedences can be expected to af= fect > >> the overall drop rate/probability seen in a session where those preced= ences > >> are mixed. > > > > Yes. And it was clearly aimed at layered video, such that there was > > a benefit to the end user in dropping the least important layer > > during lossy periods. With anything like a TCP-like congestion > > control algorithm in sight, the effects may be completely bizarre. >=20 > Reordering could make this even worse. Could different drop precedences c= ause > reordering? >=20 > Cheers, > Michael From nobody Mon Jul 21 07:54:54 2014 Return-Path: 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 AB47C1A0163 for ; Mon, 21 Jul 2014 07:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 SuLg-2upGn7x for ; Mon, 21 Jul 2014 07:54:50 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBFD1A00B8 for ; Mon, 21 Jul 2014 07:54:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,701,1400050800"; d="asc'?scan'208";a="135595332" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 21 Jul 2014 07:54:50 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Jul 2014 07:54:49 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Jul 2014 07:54:46 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::8485:306a:80a6:ba8f%21]) with mapi id 15.00.0847.030; Mon, 21 Jul 2014 07:54:47 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: wanted: minute taker Thread-Index: AQHPpPO20qlwIP2eQE2XZWcWOtEIZQ== Date: Mon, 21 Jul 2014 14:54:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_5013D3CE-DA71-4077-9F97-65E5975EC8C7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/MM7AI4xysW_YyVaqPQRqjfGnOrw Subject: [rmcat] wanted: minute taker X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "rmcat-chairs@tools.ietf.org" List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:54:51 -0000 --Apple-Mail=_5013D3CE-DA71-4077-9F97-65E5975EC8C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we're looking for a minute taker for the RMCAT sessions this week. = Please volunteer. Lars --Apple-Mail=_5013D3CE-DA71-4077-9F97-65E5975EC8C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU80pttZcnpRveo1xAQIwdQQAjRFeEEgucLlG8NLDHKuvxDJsvk20Srw3 ng1EjZkP9ltes1R0bB5t2mhgkuIbzrhgUWTgi5HafpS+jSUnGx4Ehv5vBNgdgS/a /zsvZJPr+44KJLZvWSlP73sLekzw9ioGwRwuvP4HRIoMt221+p1mrOwsLPaKzb3F /nNHcP/G4S0= =UCKp -----END PGP SIGNATURE----- --Apple-Mail=_5013D3CE-DA71-4077-9F97-65E5975EC8C7-- From nobody Tue Jul 22 15:35:31 2014 Return-Path: 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 6533F1A03C8 for ; Tue, 22 Jul 2014 15:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 mJOSdGO-KwRL for ; Tue, 22 Jul 2014 15:35:29 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CB51A039D for ; Tue, 22 Jul 2014 15:35:28 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so318420wes.5 for ; Tue, 22 Jul 2014 15:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=80gQtzc91dbk4AGOGwc6v6j3d41zi3xcPwkEcKhOO88=; b=rMnmRuVAU7ad+Lc3xFaRYoKyqv4iDOP8KPBLsEv/y7O0lussgguyn9o9DXFHzy1+T2 gK+z4KapHKJRCbfnV9V6k4FTWhS0rio9tsuZHH/9T9nx5NCX5L0F8U6ZlzW8fG0w1qKE uz+45CnKchtm7XOCJLMkW/BoI/66o5TZertRg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=80gQtzc91dbk4AGOGwc6v6j3d41zi3xcPwkEcKhOO88=; b=eVv/dAvv1Yu1Zykeqrxqvi3D/Y4/rsU2yISK1jDBK0jPXgMqUMhwYR7kbDUQhPUfwL OY0UGVErwGI8tn9AsVIjbzJZdaEckmx8Gn6wJyQaX2ABmZsWScuBmZvecpp47yGnSvbd lx3dDhBjGy72jQzwa+Hw+JIES1cwsVt+c7tBYiCuk+WV5QL7MTuk5N6ZuaX1weLK9k0A OwRH7pD8M29zTdTN/QQ+K/b/hXcTIhPs819/bjZfK5GkeaFYA5hWkrWuC2NItS2jtYK3 G84a37KJoveSqR/35hmMg6mYOlxPG1X3o1MThOjJJqPsBzzJdvg9FONkkZQ3Nn1Ra55j IWNw== X-Gm-Message-State: ALoCoQmRBd0VWm7zbwWCm+ySKXr6ken5L1AX8QiO1TDpPjthsugZg2XNANmy9/A3kUJ84dE7fAHP0GdwlFy5iLallBQ6xCvsnA== X-Received: by 10.194.134.70 with SMTP id pi6mr38967217wjb.1.1406068527109; Tue, 22 Jul 2014 15:35:27 -0700 (PDT) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+l/T9onfjNf8T2QYSaFcXcXDFB3Q== Date: Wed, 23 Jul 2014 00:35:33 +0200 Message-ID: <5b64a0eec3fc80760b89619fa96eae7b@mail.gmail.com> To: rmcat WG Content-Type: multipart/alternative; boundary=089e01175d9d169fd904fecfd793 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/n0nf9WRo6ZhAeWHZGX9E3nhvnBo Cc: "Eggert, Lars" , Mirja Kuehlewind Subject: [rmcat] Please sends slides for RMCAT sessions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:35:30 -0000 --089e01175d9d169fd904fecfd793 Content-Type: text/plain; charset=UTF-8 Please send slides material to the chairs no later than Wednesday. BR, Karen --089e01175d9d169fd904fecfd793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Please send= slides material to the chairs no later than Wednesday.

=C2=A0

BR, Karen

=C2= =A0

=C2=A0<= /span>

=C2=A0

=C2=A0<= /span>

=C2=A0

<= /html> --089e01175d9d169fd904fecfd793-- From nobody Wed Jul 23 05:26:06 2014 Return-Path: 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 37C6E1B2805 for ; Wed, 23 Jul 2014 05:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 e0VxC7fYUgAI for ; Wed, 23 Jul 2014 05:26:02 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F13A1A0B05 for ; Wed, 23 Jul 2014 05:26:01 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id k48so1117949wev.40 for ; Wed, 23 Jul 2014 05:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Pt5elvdiBRMTRhj0Krv6kPicXEBBQo6F49IJtqlUxuQ=; b=qVojt1Og9KqYjBJ18h4FWJDpf7rF5cTQfu9X6LqpcQ1XG4/QG9fWemQrI5LFd1HATk poxr0wFJLfx9Mx7yls8mue+XwHr9XpsFDJdkg1aXLwTdCKZk0CIKrnrVu8Si2gNmzYXJ OIjcQkyHQrUOG6dXIOJSTqc9BbZkPtYY/gkUZJnfw2DS9RewxUwGpK34C5DbGaiN/MV0 89Es1fge1dCQMWrlq1KwLGNfk99+8gzq8fAiqDaiClKKJrmBY1xNPeWO/Iw9qq8xYLKz QEx29JqViCmDZ9e2Rgakp6eDlGFJz5qpMTv4AR/DVN+EQELKd3b3KTvVKGI6YLAqem6N 5hDA== X-Received: by 10.194.219.225 with SMTP id pr1mr1582347wjc.34.1406118360675; Wed, 23 Jul 2014 05:26:00 -0700 (PDT) Received: from black.lan (bcdcc50f.skybroadband.com. [188.220.197.15]) by mx.google.com with ESMTPSA id eh10sm8700130wic.0.2014.07.23.05.25.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 05:25:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8FFE3475-4760-4806-BEFF-4636447F6FC3" From: Piers O'Hanlon In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290@ESESSMB205.ericsson.se> Date: Wed, 23 Jul 2014 13:25:56 +0100 Message-Id: <190452F3-F173-418A-A545-A616796D63B7@gmail.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/eFbfjku4arorICDi1i8qsnvA1tU Cc: rmcat WG , Zaheduzzaman Sarker , "iccrg@irtf.org" Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:26:05 -0000 --Apple-Mail=_8FFE3475-4760-4806-BEFF-4636447F6FC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ingemar, Thanks for your replies - more inline. Regards, Piers. On 17 Jul 2014, at 19:53, Ingemar Johansson S wrote: > Hi > =20 > Thanks for the interest in this contribution. Answers/comments inline. > =20 > Regards > Ingemar > =20 > From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com]=20 > Sent: den 17 juli 2014 13:24 > To: Ingemar Johansson S; Zaheduzzaman Sarker > Cc: iccrg@irtf.org; rmcat WG > Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc > =20 > Hi Ingemar and Zahed, > =20 > Great to see this work come to draft stage - I like the name. The = approach looks interesting - I had a couple of questions: > =20 > - 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=92t 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. > =20 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=92t 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=92t 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=92t 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. > =20 > Cheers, > =20 > Piers > =20 > =20 > =20 > On 17 Jun 2014, at 18:35, Ingemar Johansson S wrote: >=20 >=20 > Hi > =20 > 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= > =20 > Abstract : =93This 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=94 > =20 > /Ingemar > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > =93The difference between stupidity and > genius is that genius has its limits." > Albert Einstein > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 >=20 > =20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg --Apple-Mail=_8FFE3475-4760-4806-BEFF-4636447F6FC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Ingemar,

Thanks for your replies - more = inline.

Regards,

Piers.<= /div>


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

From: Piers O'Hanlon = [mailto:p.ohanlon@gmail.com] 
Sent: den 17 juli 2014 = 13:24
To: Ingemar Johansson S; = Zaheduzzaman Sarker
Cc: iccrg@irtf.org; 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=92t 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.
- 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=92t 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=92t 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=92t 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.


On 17 Jun 2014, at 18:35, = Ingemar Johansson S wrote:
This draft = can be of interest for those of you interested in congestion control for = realtime media.
SMS/MMS +46-73 078 3289ingemar.s.johansson@ericsson.comwww.ericsson.com =93The difference between stupidity andgenius is that = genius has its limits."
Albert = Einstein

 iccrg@irtf.org
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:56:15 -0000 Hi all, If everyone is in agreement, I will generate a new version of the eval-criteria document incorporating the feedback in the next couple of days. Cheers, Varun. On Wed, Jul 16, 2014 at 2:05 PM, Michael Welzl wrote: > Hi, > > In line: > > > On 14. juli 2014, at 16:37, Varun Singh wrote: > >> Hi Michael, >> >> Missed this email from earlier, comments inline. >> >> Cheers, >> Varun >> >> On Fri, Jun 13, 2014 at 4:07 PM, Michael Welzl wrot= e: >>> Hi, >>> >>> On 12. juni 2014, at 13:28, Varun Singh wrote: >>> >>>> Hi all, >>>> >>>> There was one one open issue that needs to be discussed and it is >>>> related to fairness :) >>>> >>>> This has been discussed at length in the design group meetings and >>>> also at the IETF meetings, but I am not sure if the text in the open >>>> issue had working group agreement. >>>> >>>> The summary of the discussion so far is: >>>> - The eval-criteria needs to define a guideline that helps in >>>> evaluating an RMCAT proposal >>>> - The individual test case should define its expected fairness >>>> criteria, and it may vary between scenarios. >>>> >>>> NEW TEXT to replace the open issue: >>>> >>>> Fairness or Unfairness: Experiments testing the performance of an >>>> RMCAT proposal against any cross-traffic must define its expected >>>> criteria for fairness. >>>> >>>> The "unfairness" test guideline to assist in defining such a >>>> criteria (measured at 1s intervals) is: >>>> 1. Does not trigger the circuit breaker. >>>> 2. When the competing streams with identical RMCAT streams having >>>> similar RTTs, >>>> no stream achieves over 3 times the min RMCAT stream or less than >>>> 1/3 times the >>>> throughput of the max RMCAT stream. >>> >>> In principle, what this new text up to here is trying to say (if I inte= rpret it correctly) sounds good to me. >>> However, the English is pretty broken, please fix. >>> >> >> 2. When competing with identical RMCAT streams having similar RTTs, >> no RMCAT stream achieves >> more than 3 times the average throughput of the RMCAT stream with the >> lowest average throughput, >> or less than 1/3 times the average throughput of the RMCAT stream with >> the highest average throughput. > > Looks fine to me > > >>>> 3. When competing with identical RMCAT streams having similar RTTs, >>>> no RTT measurements for an RMCAT stream is over 3 times delay compare= d to RTT >>>> measurements performed before starting the RMCAT flow. >>> >>> Huh? "Compared to measurements performed before starting the RMCAT flow= " =3D> which one? All, including the background flows, or only the foregrou= nd flow? The foreground flow must not make the RTT grow by a factor of 3, i= s that it? I think that's not a fairness criterion, it's a delay-minimizing= criterion, and a weird one too. I wonder if this could just be removed. >> >> My interpretation of the proposal was that the RTT should not grow by >> a factor of 3 for the existing flows when a new flow is added. I can >> remove this, if there is consensus on removing this requirement. > > Ah, got it. I'm fine with the requirement (although I stick with my obser= vation that it's kinda weird :) ). Anyway I'd rephrase it as you wrote it= here, which is much easier to understand than your original text. > > Cheers, > Michael > > > >> I do not remember correctly who made the original proposal (was >> perhaps Kevin Gross), but was in a design meeting from a year ago. >> >>> >>> Cheers, >>> Michael >>> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Wed Jul 23 11:31:34 2014 Return-Path: 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 828671B2C02 for ; Wed, 23 Jul 2014 11:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 WhTcRW5EZRb7 for ; Wed, 23 Jul 2014 11:31:26 -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 117E31B2800 for ; Wed, 23 Jul 2014 11:31:24 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-4e-53cfff7b429a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.A8.03739.B7FFFC35; Wed, 23 Jul 2014 20:31:23 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.206]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 20:31:22 +0200 From: Zaheduzzaman Sarker To: Piers O'Hanlon , Ingemar Johansson S Thread-Topic: [iccrg] draft-johansson-rmcat-scream-cc Thread-Index: AQHPobGmHkIRUIoSc0CO9CVxTJRvkZuke9eAgAkBvwCAAIb3kA== Date: Wed, 23 Jul 2014 18:31:22 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290@ESESSMB205.ericsson.se> <190452F3-F173-418A-A545-A616796D63B7@gmail.com> In-Reply-To: <190452F3-F173-418A-A545-A616796D63B7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_E0F7A68B07B53F4FBD12DABD61CBA90E1273E95DESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rrf6//lgg7Y+KYsDC3ayW+ybMZHR YvXND2wOzB47Z91l91iy5CeTx+SNh9kCmKO4bFJSczLLUov07RK4MmZO7mErWP2JseJYTwN7 A+Pty4xdjBwcEgImEq3HebsYOYFMMYkL99azdTFycQgJHGWUWNP/lxHCWcIo8WfJDlaQBjYB G4nHi/1ATBGBJIkLL41AepkFHCSOT13MBGILA4189XEGG4gtImAq8XbpWijbSWLP4yvMIDaL gKrEip2/WUFsXgFfib7vx5ggVn1nlPi/4i8LSIJTwFZie+s/dhCbEei476fWMEEsE5e49WQ+ E8TRAhJL9pxnhrBFJV4+/scKYStJrNh+CexHZoF8iWurOCF2CUqcnPmEZQKj6Cwkk2YhVM1C UgVRoidxY+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tL LdnECIzAg1t+6+5gXP3a8RCjAAejEg/vg/3ng4VYE8uKK3MPMUpzsCiJ8y46Ny9YSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA6MGy8X709lT7v6eGfx3d/43jk915Zumpa4rvZzL8n3b2trJ ljWf1sV8dGTOWDqj+eKM6T9FMzJdmHMXOM978+AC8+HW670vG/mOVprM2XbKh1fz1NkvTr5/ 4oK/SLtVHdreJfGISypsSpttN8utzBVTH/hz5JgKJXQ1iR5OiuTZGmVm8+q/RosSS3FGoqEW c1FxIgAe8qBmoQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/tUHW_xi-jB_HxRdWmYPBRXCYimY Cc: rmcat WG , "iccrg@irtf.org" Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:31:30 -0000 --_000_E0F7A68B07B53F4FBD12DABD61CBA90E1273E95DESESSMB307erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Piers, Thanks for the comments. Could you please send us pointers to the research papers you mentioned in y= our reply regarding performance issue with "media on hold" in the wireline = network?. BR Zahed From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com] Sent: den 23 juli 2014 08:26 To: Ingemar Johansson S Cc: Zaheduzzaman Sarker; iccrg@irtf.org; 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:p.ohanlon@gmail.com] Sent: den 17 juli 2014 13:24 To: Ingemar Johansson S; Zaheduzzaman Sarker Cc: iccrg@irtf.org; 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 adv= antage, delay-impact on other flows, and yielding behaviour to short of lon= ger lived TCP flows etc. [IJ] Zahed will present a few test cases at the RMCAT WG sessions. A few ad= ditional comments. Yes, I have see similar issues that are reported for LED= BAT in terms of late comers advantage etc. also in SCReAM, the current solu= tion 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 p= eriod. 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 do= n'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 gi= ven in the presentation. I guess this sort of technique may be more likely to work in LTE type of en= vironments 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 e= ffective? 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 o= f low delay. And also I assume that it's behaviour would be similar to LEDBAT when compe= ting 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 TARGE= T 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 t= he code, the adaptive delay target function use the same technique to put t= he 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 th= is 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 LED= BAT, will look it up when I am back from the vacation for good in mid Augus= t 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 - Mobi= le provides for very noisy environments I wondered if you had any alternati= ves? [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 adjustmen= t. I guess it depends on the variation of the noise - what sort of variation d= o 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 con= trol 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 conversatio= nal 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "The difference between stupidity and genius is that genius has its limits." Albert Einstein =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ iccrg mailing list iccrg@irtf.org https://www.irtf.org/mailman/listinfo/iccrg --_000_E0F7A68B07B53F4FBD12DABD61CBA90E1273E95DESESSMB307erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Piers,

Thanks for the comments.<= o:p>

Could you please send us = pointers to the research papers you mentioned in your reply regarding perfo= rmance issue with “media on hold” in the wireline network?.

 <= /p>

BR

 <= /p>

Zahed

 <= /p>

 <= /p>

From: Piers O'= Hanlon [mailto:p.ohanlon@gmail.com]
Sent: den 23 juli 2014 08:26
To: Ingemar Johansson S
Cc: Zaheduzzaman Sarker; iccrg@irtf.org; 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

 <= /p>

Thanks for the interest i= n this contribution. Answers/comments inline.

 <= /p>

Regards=

Ingemar=

 <= /p>

 

Hi Ingemar and&= nbsp;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 yo= u had looked into some of the issues it suffers from like; intra-procotol f= airness, late-comer advantage, delay-impact on other flows, and yielding be= haviour 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 t= o this is to put media on hold for about one RTT at regular intervals if th= e 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.

 <= /p>

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 measur= ement...? 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 simil= ar to LEDBAT when competing with TCP type flows?

 



- It is mentioned that there's an 'Adaptive delay ta= rget' - but in the code owdTarget does not change - Did you have strat= egies 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 no= t yet any adaptive target delay functionality in the code, the adaptive del= ay 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 the= re 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 diffe= rent flows end up with different targets and suffer or do they correct them= selves quickly enough?

 

- What period do use to measure the Base Delay (or d= o use LEDBAT's 1 minute value) - the default seems quite high for mobile de= ployments...?

[IJ] Don’t remember= right now but it is definitely shorter than default LEDBAT, will look it u= p when I am back from the vacation for good in mid August=

It would be interesting to know how the actual RTT o= f on LTE can vary as a user moves, and I imagine handovers would lead to so= me complications.



- What sort of filtering do you propose for queuing = delay beyond MIN - Mobile provides for very noisy environments I wondered i= f you had any alternatives?

[IJ] Yes it is noisy but = sofar I don’t use any filtering at all, seems like it is sufficient w= ith the filtering that is inherent in the CWND adjustment.

I guess it depends on the variation of the noise - w= hat sort of variation do you typically see?



- How does it compete against a LEDBAT flow with a s= imilar 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 t= o 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.

 

Abstract : “This memo describes a= rate adaptation framework for conversational

   video services.  The = solution conforms to the packet conservation

   principle and uses a hybri= d loss and delay based congestion control

   algorithm.  The frame= work is evaluated over both simulated bottleneck

   scenarios as well as in a = LTE (Long Term Evolution) system simulator

   and is shown to achieve bo= th low latency and high video throughput in

   these scenariosR= 21;

 

/Ingemar<= /p>

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.=

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 

“The difference between stupidity and

genius is th= at genius has its limits."
Albert Einstein
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.or= g/mailman/listinfo/iccrg

 

--_000_E0F7A68B07B53F4FBD12DABD61CBA90E1273E95DESESSMB307erics_-- From nobody Wed Jul 23 15:27:59 2014 Return-Path: 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 116CF1B2964 for ; Wed, 23 Jul 2014 15:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 fU4yVhfRCKfS for ; Wed, 23 Jul 2014 15:27:56 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12FE1A0322 for ; Wed, 23 Jul 2014 15:27:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,720,1400050800"; d="asc'?scan'208";a="136121760" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 23 Jul 2014 15:27:57 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 23 Jul 2014 15:27:55 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 23 Jul 2014 15:27:36 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::8485:306a:80a6:ba8f%21]) with mapi id 15.00.0847.030; Wed, 23 Jul 2014 15:27:36 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: IPR Disclosure: Lars Eggert's Statement about IPR related to draft-singh-rmcat-adaptive-fec-00 belonging to Nokia Thread-Index: AQHPpsMdBio4NpYGeUCLtpN7rqc5cQ== Date: Wed, 23 Jul 2014 22:27:36 +0000 Message-ID: References: <20140723221148.10575.54434.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_155A5349-28F9-4300-BBB7-89FC7E1C1841"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/cciavfmZaDIvY4RQ7VoSWlaQ_wY Subject: [rmcat] Fwd: IPR Disclosure: Lars Eggert's Statement about IPR related to draft-singh-rmcat-adaptive-fec-00 belonging to Nokia 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:27:58 -0000 --Apple-Mail=_155A5349-28F9-4300-BBB7-89FC7E1C1841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI I expect Nokia to make a first-party disclosure in a little while. Begin forwarded message: > From: IETF Secretariat > Subject: IPR Disclosure: Lars Eggert's Statement about IPR related to = draft-singh-rmcat-adaptive-fec-00 belonging to Nokia > Date: July 23, 2014 at 18:11:48 EDT > To: , , , = > Cc: , >=20 >=20 > Dear Varun Singh, Marcin Nagy, Joerg Ott, Lars Eggert: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Congestion > Control Using FEC for Conversational Media" = (draft-singh-rmcat-adaptive-fec) was > submitted to the IETF Secretariat on 2014-07-23 and has been posted on = the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2394/). The title of the IPR = disclosure is > "Lars Eggert's Statement about IPR related to = draft-singh-rmcat-adaptive-fec-00 > belonging to Nokia.""); >=20 > The IETF Secretariat >=20 --Apple-Mail=_155A5349-28F9-4300-BBB7-89FC7E1C1841 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU9A22NZcnpRveo1xAQLhowP9E+s2IXHn/le7L1USifEgliqHkHzg94jF S2g1dTDL71AIUyfxb986IGl5bt3DMAj91J2ntHQ1/T58A5vGIwA5PvWlj7t2amaQ UoHQcrzSx57/sAUoWo0mnEXui4x02P36iFt2edjjSvYKeREqwwqVE5v8s4XRBXCw kZasb9LvPjY= =o88y -----END PGP SIGNATURE----- --Apple-Mail=_155A5349-28F9-4300-BBB7-89FC7E1C1841-- From nobody Wed Jul 23 20:21:46 2014 Return-Path: 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 7C91C1A01E6 for ; Wed, 23 Jul 2014 20:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7] 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 ad8XFSgM03fA for ; Wed, 23 Jul 2014 20:21:40 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D3D1A03BC for ; Wed, 23 Jul 2014 20:21:37 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 24 Jul 2014 05:21:02 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 31.133.150.168 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: rmcat@ietf.org Message-ID: <53D07BAF.7000403@kau.se> Date: Thu, 24 Jul 2014 05:21:19 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <201403311602.49284.mirja.kuehlewind@ikr.uni-stuttgart.de> <8B1B16F2-3E29-4817-9B22-F76E9957AEFA@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/FJtfg_pYJbaL4VKEzVCsCI90Kxg Subject: Re: [rmcat] Please review draft-ietf-rmcat-eval-criteria-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 03:21:45 -0000 Hi Varun, On 2014-07-23 15:55, Varun Singh wrote: [snip] >>> 2. When competing with identical RMCAT streams having similar RTTs, >>> no RMCAT stream achieves >>> more than 3 times the average throughput of the RMCAT stream with the >>> lowest average throughput, >>> or less than 1/3 times the average throughput of the RMCAT stream with >>> the highest average throughput. >> Looks fine to me Unless I am missing something, the above text states the same criteria twice. Is this intended/needed? Cheers, Anna From nobody Thu Jul 24 02:03:24 2014 Return-Path: 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 2107E1A010F for ; Thu, 24 Jul 2014 02:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 jvbcBFIzbLll for ; Thu, 24 Jul 2014 02:03:18 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64CF51A0125 for ; Thu, 24 Jul 2014 02:03:13 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so8774536wiv.4 for ; Thu, 24 Jul 2014 02:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=VQWkK3Ua3fLA4nuBBs454eXHRntmJuzcohAnUGC8kwA=; b=BxjsPRk+XN1sbeMRdCAypXMwGviGGgcmnc/REbxVyUMQ8fvJfpOPSh6qzoep1i6PMj O1r9lm/85hPKgDx0V3LJYSeh0+4G49UhS1/rGZ3vEY6drvl5OYsH73um4VSiJ/ur0DYD H9QFMqu5lNxwmDluMkrsmIIWqYVpVfLASZ8jDvbDwY2xeYUSwJ929mlkc1ljDuaniskq tQ1O5oZcCl6jQSUfT9iHqQ7Edh/GYxH1U4r2W32dMj9Ip5uITwzmsMDwKLFLAeS9S9XK l8LYUYCtraIom2mtsIJ1YK69K5orn0/RYnFQlPWGNNUI8NetLkjJBovKQjt+5GVPJ4Y7 +vaw== X-Received: by 10.180.39.73 with SMTP id n9mr10877330wik.70.1406192590622; Thu, 24 Jul 2014 02:03:10 -0700 (PDT) Received: from black.lan (bcdcc50f.skybroadband.com. [188.220.197.15]) by mx.google.com with ESMTPSA id hp6sm20201281wib.23.2014.07.24.02.03.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 02:03:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E9B2F98F-A21C-4A45-9852-3746AA07BF1B" From: Piers O'Hanlon In-Reply-To: Date: Thu, 24 Jul 2014 10:03:05 +0100 Message-Id: <5563B4E8-D0F2-4C69-B34C-D6453ECCF774@gmail.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290@ESESSMB205.ericsson.se> <190452F3-F173-418A-A545-A616796D63B7@gmail.com> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/FXUKwdaSwXYVayQsXA-GQelby5c Cc: Ingemar Johansson S , rmcat WG , "iccrg@irtf.org" Subject: Re: [rmcat] [iccrg] draft-johansson-rmcat-scream-cc 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 09:03:23 -0000 --Apple-Mail=_E9B2F98F-A21C-4A45-9852-3746AA07BF1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 =93media on hold=94 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 =20 > =20 > BR > =20 > Zahed > =20 > =20 > From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com]=20 > Sent: den 23 juli 2014 08:26 > To: Ingemar Johansson S > Cc: Zaheduzzaman Sarker; iccrg@irtf.org; rmcat WG > Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc > =20 > Hi Ingemar, > =20 > Thanks for your replies - more inline. > =20 > Regards, > =20 > Piers. > =20 > =20 > On 17 Jul 2014, at 19:53, Ingemar Johansson S wrote: >=20 >=20 > Hi > =20 > Thanks for the interest in this contribution. Answers/comments inline. > =20 > Regards > Ingemar > =20 > From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com]=20 > Sent: den 17 juli 2014 13:24 > To: Ingemar Johansson S; Zaheduzzaman Sarker > Cc: iccrg@irtf.org; rmcat WG > Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc > =20 > Hi Ingemar and Zahed, > =20 > Great to see this work come to draft stage - I like the name. The = approach looks interesting - I had a couple of questions: > =20 > - 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=92t 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. > =20 > 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. > =20 > And also I assume that it's behaviour would be similar to LEDBAT when = competing with TCP type flows? > =20 >=20 >=20 > - 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? > =20 > - 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=92t 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. >=20 >=20 > - 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=92t 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? >=20 >=20 > - How does it compete against a LEDBAT flow with a similar target? > [IJ] We don=92t 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. > =20 >=20 >=20 > =20 > Cheers, > =20 > Piers > =20 > =20 > =20 > On 17 Jun 2014, at 18:35, Ingemar Johansson S wrote: >=20 >=20 >=20 > Hi > =20 > 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= > =20 > Abstract : =93This 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=94 > =20 > /Ingemar > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > =93The difference between stupidity and > genius is that genius has its limits." > Albert Einstein > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 >=20 > =20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg --Apple-Mail=_E9B2F98F-A21C-4A45-9852-3746AA07BF1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Zahed,

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

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

Piers
 
 Piers = O'Hanlon [mailto:p.ohanlon@gmail.com] 
Sent: den 23 juli 2014 = 08:26
To: Ingemar Johansson = S
Cc: Zaheduzzaman Sarker; iccrg@irtf.org; rmcat = WG
Subject: Re: [iccrg] = draft-johansson-rmcat-scream-cc
 
Hi = Ingemar,
Thanks for your replies - = more inline.
On 17 Jul 2014, at 19:53, = Ingemar Johansson S wrote:
Thanks for the interest in this contribution. = Answers/comments inline.
Regards
 
Piers O'Hanlon [mailto:p.ohanlon@gmail.com] 
Sent: den 17 juli 2014 = 13:24
To: Ingemar Johansson S; = Zaheduzzaman Sarker
Cc: iccrg@irtf.org; rmcat WG
Subject: Re: [iccrg] = draft-johansson-rmcat-scream-cc
<= div>
 
Hi I 
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=92t 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=92t 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=92t 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=92t 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.
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.
genius is that = genius has its limits."
Albert = Einstein
iccrg@irtf.org
, Colin Perkins Subject: [rmcat] Requirements spec and Jitter 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:23:35 -0000 Regarding why Jitter doesn't appear as a requirement in the draft: I think delay variation (and perhaps more importantly, delay response to cross traffic changes) will be seen in the responses to the evaluation criteria. I don't think we could say much in the requirements - and keeping delay variation low implies living with higher delay on average; variation as low-as-possible would mean much higher delay (generally). So it competes with the primary goal. Also, delay jitter is normally absorbed by the jitter buffers - the net result is that if we reduce transfer jitter, the jitter buffer will contract (but generally not by as much as we reduce transfer jitter), again leading to longer end-to-end media delays. Getting the data to the jitter buffer with as low a delay as possible generally lets the jitter buffer and adaptive resampling do it's job; and the application can tune those to provide the level of user-visible delay variation it wants. There are cases where large packet-to-packet delay can cause a jitter buffer to run larger than you'd like, but this gets deep into the specific design of the jitter buffer, and would tie the spec to a specific definition of a jitter buffer if we try to lock it down. So, I think we should keep with our primary goal, and not try to mix jitter control explicitly into it, and let the jitter buffers and other application tools decide how to process the data. (I wouldn't say we don't care *at all*, but it's a lower level of concern, and I don't think any proposed algorithm would fail to provide a reasonable delay profile over time - and so I wouldn't make it a requirement, and I don't think we should spend time arguing over what's "reasonable" or what are hard requirements when I don't think it will even come into play. It's like "Fairness".) I'll also note that "Jitter" usually implies low-duration events; and we care mostly about total mouth-to-ear delay - and medium-to-long term measures of delay are important. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Thu Jul 24 12:54:47 2014 Return-Path: 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 2AD9E1A0AC8; Thu, 24 Jul 2014 12:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6O4RWrfAdwMp; Thu, 24 Jul 2014 12:54:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F341A0444; Thu, 24 Jul 2014 12:54:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724195443.12411.84231.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 12:54:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/2C16Ke9jtS7CfNwBZOSv6FWZ69M Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-rtp-cc-feedback-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:54:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia Congestion Control Author : Colin Perkins Filename : draft-ietf-rmcat-rtp-cc-feedback-00.txt Pages : 8 Date : 2014-07-24 Abstract: This memo discusses the types of congestion control feedback that it is possible to send using the RTP Control Protocol (RTCP), and their suitability of use in implementing congestion control for unicast multimedia applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 24 13:21:40 2014 Return-Path: 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 BDD341A0194 for ; Thu, 24 Jul 2014 13:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 weN_8zTmgECt for ; Thu, 24 Jul 2014 13:21:28 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EB71B2809 for ; Thu, 24 Jul 2014 13:21:26 -0700 (PDT) Received: from [31.133.155.225] (port=64042 helo=dhcp-9be1.meeting.ietf.org) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XAPW0-0004TD-8v; Thu, 24 Jul 2014 21:21:24 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53D140AE.7090305@jesup.org> Date: Thu, 24 Jul 2014 16:21:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <298496B2-84FC-4B54-9933-3A85BBDD913E@csperkins.org> References: <201406121419.51042.mirja.kuehlewind@ikr.uni-stuttgart.de> <5399C9D5.8030007@jesup.org> <201407031839.00178.mirja.kuehlewind@ikr.uni-stuttgart.de> <53B59514.8030401@jesup.org> <1f3abfb82e8dd62eda8afeda45b3271b@mail.gmail.com> <53BF6D4C.70300@jesup.org> <53D140AE.7090305@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/cmKD93_LNCzGvnZNsYRfVnKIByQ Cc: rmcat WG , "Eggert, Lars" , =?iso-8859-1?Q?Mirja_K=FChlewind?= Subject: Re: [rmcat] Requirements spec and Jitter 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:21:33 -0000 So, I think the requirement should be low overall latency. =46rom the = transport perspective, the most important component of that is transit = delay, I agree, but transit delay variation (i.e., jitter) does affect = the overall latency, and I think should be mentioned.=20 Colin On 24 Jul 2014, at 13:21, Randell Jesup wrote: > Regarding why Jitter doesn't appear as a requirement in the draft: >=20 > I think delay variation (and perhaps more importantly, delay response = to cross traffic changes) will be seen in the responses to the = evaluation criteria. I don't think we could say much in the = requirements - and keeping delay variation low implies living with = higher delay on average; variation as low-as-possible would mean much = higher delay (generally). So it competes with the primary goal. Also, = delay jitter is normally absorbed by the jitter buffers - the net result = is that if we reduce transfer jitter, the jitter buffer will contract = (but generally not by as much as we reduce transfer jitter), again = leading to longer end-to-end media delays. Getting the data to the = jitter buffer with as low a delay as possible generally lets the jitter = buffer and adaptive resampling do it's job; and the application can tune = those to provide the level of user-visible delay variation it wants. = There are cases where large packet-to-packet delay can cause a jitter = buffer to run larger than you'd like, but this gets deep into the = specific design of the jitter buffer, and would tie the spec to a = specific definition of a jitter buffer if we try to lock it down. >=20 > So, I think we should keep with our primary goal, and not try to mix = jitter control explicitly into it, and let the jitter buffers and other = application tools decide how to process the data. >=20 > (I wouldn't say we don't care *at all*, but it's a lower level of = concern, and I don't think any proposed algorithm would fail to provide = a reasonable delay profile over time - and so I wouldn't make it a = requirement, and I don't think we should spend time arguing over what's = "reasonable" or what are hard requirements when I don't think it will = even come into play. It's like "Fairness".) >=20 > I'll also note that "Jitter" usually implies low-duration events; and = we care mostly about total mouth-to-ear delay - and medium-to-long term = measures of delay are important. >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com --=20 Colin Perkins http://csperkins.org/ From nobody Thu Jul 24 13:23:49 2014 Return-Path: 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 B78891B286A for ; Thu, 24 Jul 2014 13:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cOvMN1Va3WLe for ; Thu, 24 Jul 2014 13:23:44 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA871B27B0 for ; Thu, 24 Jul 2014 13:23:44 -0700 (PDT) Received: from [31.133.155.225] (port=64068 helo=dhcp-9be1.meeting.ietf.org) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XAPYE-0004ly-Ps for rmcat@ietf.org; Thu, 24 Jul 2014 21:23:43 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20140724195443.12411.84231.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 16:23:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <550E0342-E23B-4BA9-9353-F93C3FE6C72D@csperkins.org> References: <20140724195443.12411.84231.idtracker@ietfa.amsl.com> To: rmcat WG X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/r5Hq3ctaFuUx11335qmw7CwnSsY Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-rtp-cc-feedback-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:23:46 -0000 This version is identical to the last individual draft, apart from the = date and filename. Colin On 24 Jul 2014, at 15:54, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the RTP Media Congestion Avoidance = Techniques Working Group of the IETF. >=20 > Title : Using RTP Control Protocol (RTCP) Feedback = for Unicast Multimedia Congestion Control > Author : Colin Perkins > Filename : draft-ietf-rmcat-rtp-cc-feedback-00.txt > Pages : 8 > Date : 2014-07-24 >=20 > Abstract: > This memo discusses the types of congestion control feedback that it > is possible to send using the RTP Control Protocol (RTCP), and their > suitability of use in implementing congestion control for unicast > multimedia applications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-feedback-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Fri Jul 25 05:14:23 2014 Return-Path: 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 BA0971B27D5 for ; Fri, 25 Jul 2014 05:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 4Kx7HnE6Uj4H for ; Fri, 25 Jul 2014 05:14:18 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB6A1A01AC for ; Fri, 25 Jul 2014 05:14:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,730,1400050800"; d="asc'?scan'208";a="136444125" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 25 Jul 2014 05:14:18 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 25 Jul 2014 05:14:17 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 25 Jul 2014 05:14:17 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::8485:306a:80a6:ba8f%21]) with mapi id 15.00.0847.030; Fri, 25 Jul 2014 05:14:17 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: Summary of Toronto decisions Thread-Index: AQHPqAH0rgRtAY5g+k6S6YrWsx0gGA== Date: Fri, 25 Jul 2014 12:14:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_391A3E7C-F42B-4BE2-BE95-E6CFFB8969B8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/b5W67wMhNiQCptgPIUybH5NUAeY Subject: [rmcat] Summary of Toronto decisions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:14:21 -0000 --Apple-Mail=_391A3E7C-F42B-4BE2-BE95-E6CFFB8969B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we'll have the detailed minutes up shortly (thank you, Gorry). In the meantime, I wanted to summarize the decisions we took and confirm = them on the list: * draft-perkins-rmcat-rtp-cc-feedback adopted as WG item * draft-sarker-rmcat-eval-test adopted as WG item * draft-zanaty-rmcat-app-interaction adopted as WG item Please speak up if you disagree with these decisions. Also, it became clear that we need additional meeting time in order to = take a look at the evaluation of the current candidates in more detail. = This will likely take more time than we can get during an IETF week. = There are a few options for us here: * virtual interims (Webex) * physical interim together with RTCWEB (if they happen to schedule one = soon) * physical interim just for RMCAT * long side meeting Sat or Sun in Honolulu If you have a preference, please email rmcat-chairs@tools.ietf.org Thanks, Lars --Apple-Mail=_391A3E7C-F42B-4BE2-BE95-E6CFFB8969B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU9JKGNZcnpRveo1xAQLGkQP/UK/KX1GyWczb6X0kcHJnpUnQJC7929Yd L3u4+xUxPUpZNJhpdHrEn4IQnZmCVfHJ3K7pmtWmmE2p+ZrtpXdE+ByehbeCDMAp DwwiPmPnnQkbja9uQr1496xS5u7Cgnsep7nCrdxZEupGuNKQbaODFm5swTZkRs2u f/lxmhiUQHk= =WnW5 -----END PGP SIGNATURE----- --Apple-Mail=_391A3E7C-F42B-4BE2-BE95-E6CFFB8969B8-- From nobody Fri Jul 25 07:04:27 2014 Return-Path: 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 7B5531A0316 for ; Fri, 25 Jul 2014 07:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 g9p3i268inkr for ; Fri, 25 Jul 2014 07:04:20 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CDB1B2910 for ; Fri, 25 Jul 2014 07:03:08 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so3770423iec.1 for ; Fri, 25 Jul 2014 07:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xNo/+9bziaonGs6o+iHOFdPpX2aML8ePFJ8NRZ5bnkg=; b=e1FieFbX86aojOn+ePdkTVXkGUu4s+Y9T0g50JkjHLmqV43QKZLsK8WI+QpbZI3lGj CBPXJK+jwiXvdKqndujoPXzUz9bbNNyu9odtZJOOJUdudxMaZYztUP13I/jPvjXc9+l+ PJvSa0jr6Y0QHOqjAn0cjppN51/5mOjabZH7HGhjqp4tSs2g7DOU+0TAQ+eSl0rMEUGL nvk2hN9+qkFZggDeiUG6In+rB2y0Op/9fDRJ+5C1YVeu3rkMh8ASfNNk0SkSYgfFICIK JDnOlxheL+qKpqwu9eP4GomBc+vANFaZwJB3FigZlKLzTRrwn/Y0SdUzKk1chCGuwk+7 NFFA== X-Received: by 10.42.212.146 with SMTP id gs18mr2993814icb.96.1406296987403; Fri, 25 Jul 2014 07:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.251.175 with HTTP; Fri, 25 Jul 2014 07:02:47 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Fri, 25 Jul 2014 10:02:47 -0400 Message-ID: To: rmcat WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/zAti-2bWlON3UyzbdXllNILGO2Y Subject: Re: [rmcat] Summary of Toronto decisions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:04:25 -0000 On Fri, Jul 25, 2014 at 8:14 AM, Eggert, Lars wrote: > Hi, > > we'll have the detailed minutes up shortly (thank you, Gorry). > > In the meantime, I wanted to summarize the decisions we took and confirm them on the list: > > * draft-perkins-rmcat-rtp-cc-feedback adopted as WG item I reaffirm the support for adoption of the draft because it provides useful guidance to all RMCAT CC proposals. > > Thanks, > Lars > -- http://www.netlab.tkk.fi/~varun/ From nobody Fri Jul 25 08:10:24 2014 Return-Path: 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 392981A02E1; Fri, 25 Jul 2014 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eL1DGA-_-DTQ; Fri, 25 Jul 2014 08:09:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 028D21A0012; Fri, 25 Jul 2014 08:09:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140725150949.2350.83343.idtracker@ietfa.amsl.com> Date: Fri, 25 Jul 2014 08:09:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/CmdM7c4XEzDeDJNvN-9XpBOFkDs Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-eval-criteria-02.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:09:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Evaluating Congestion Control for Interactive Real-time Media Authors : Varun Singh Joerg Ott Filename : draft-ietf-rmcat-eval-criteria-02.txt Pages : 12 Date : 2014-07-25 Abstract: The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-eval-criteria-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-eval-criteria-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 25 08:22:31 2014 Return-Path: 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 E25EB1B27D8 for ; Fri, 25 Jul 2014 08:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 709DevbhCusr for ; Fri, 25 Jul 2014 08:22:23 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C0F1A0277 for ; Fri, 25 Jul 2014 08:22:23 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rd18so3904607iec.28 for ; Fri, 25 Jul 2014 08:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=3QI4oo4PlbmWFJu2aDwnuSxSCjPoG89mwg52vGyH914=; b=GA6+c92pyWcyJ/RFVCkMncCEJM9LYOZYfCXFK9lYGqbh346NQYpxrp6Hada1qv8+rd U5MG5BioVJiZtt2ATRytRb9aYR+JzS+SVVMOsAC3oCN7Oqas33syhIcav4NpeXNjw3W4 BzSYjs7A07D1Q4ZLJoJWqlmaqAG/GaY5vTAMgqgChra7yHxYJ5Odq8aX1nEitQUstoTK BFBV++2pt5l3Ws/bxf1AbeyF4Xqc7JfHwSqN7CJqL9NX2BBwIX2i+hUd3jh/OUJPFR8r +wUFKCekHskpO+yjhvk+jwf+EfX5brEW413Fs0m8bVMS53rqc44Dxx4sRzSRNZy5ocmp v6dg== X-Received: by 10.42.139.4 with SMTP id e4mr20812659icu.73.1406301742094; Fri, 25 Jul 2014 08:22:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.251.175 with HTTP; Fri, 25 Jul 2014 08:22:01 -0700 (PDT) In-Reply-To: <20140725150949.2350.83343.idtracker@ietfa.amsl.com> References: <20140725150949.2350.83343.idtracker@ietfa.amsl.com> From: Varun Singh Date: Fri, 25 Jul 2014 11:22:01 -0400 Message-ID: To: rmcat WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/oigpW2R9MKsEsBagqEj1mc0bizA Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-eval-criteria-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:22:25 -0000 The new submission applies the changes based on the feedback from Anna Brunstrom and Michael Welzl. It expands the open issue related to Jain Fairness Index raised by Karen. Copying the open issue below: Open issue (1): Using Jain-fairness index (JFI) for measuring self-fairness between RTP flows? measured at what intervals? visualized as a CDF or a time-series? Additionally: Use JFI for comparing fairness between RTP and long TCP flows? On Fri, Jul 25, 2014 at 11:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. > > Title : Evaluating Congestion Control for Interactive Real-time Media > Authors : Varun Singh > Joerg Ott > Filename : draft-ietf-rmcat-eval-criteria-02.txt > Pages : 12 > Date : 2014-07-25 > > Abstract: > The Real-time Transport Protocol (RTP) is used to transmit media in > telephony and video conferencing applications. This document > describes the guidelines to evaluate new congestion control > algorithms for interactive point-to-point real-time media. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-eval-criteria-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-eval-criteria-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- http://www.netlab.tkk.fi/~varun/ From nobody Mon Jul 28 04:31:35 2014 Return-Path: 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 6F9F41A014C for ; Mon, 28 Jul 2014 04:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 KNSjlsEWQQC8 for ; Mon, 28 Jul 2014 04:31:28 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3F21A00D5 for ; Mon, 28 Jul 2014 04:31:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,748,1400050800"; d="asc'?scan'208";a="136869858" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 28 Jul 2014 04:31:28 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Jul 2014 04:31:28 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 28 Jul 2014 04:31:28 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.0913.011; Mon, 28 Jul 2014 04:31:27 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: please check prelim minutes Thread-Index: AQHPqld31ZesnIUPekqcZT4ckAYs4g== Date: Mon, 28 Jul 2014 11:31:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_CDA7FB30-A3C4-449B-BCB9-FEF6EAC15A11"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/IaOt5aQ-VVLCSIRfWSKmADMPZ8E Subject: [rmcat] please check prelim minutes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 11:31:33 -0000 --Apple-Mail=_CDA7FB30-A3C4-449B-BCB9-FEF6EAC15A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, please check and correct/expand our preliminary minutes from Toronto on = http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-rmcat?useMonospaceFont= =3Dtrue Thanks, Lars --Apple-Mail=_CDA7FB30-A3C4-449B-BCB9-FEF6EAC15A11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU9Y0jtZcnpRveo1xAQKqlwP7BP/sX+bY0T5DivLEUrpQoyYbpXKxzZTW /sjU1HlVNR7grZor6UTDvU/yQWBGKTZ1nGLnflKtInkKcMcGocKCMCjphWf5R5a3 UuihXK8TZmg7ek+H0TQIV1ge0FObcpvQl52spLYL8C6emO4f/rvx7cSVQUsLMCes VdEtP8gs0e0= =Q7p1 -----END PGP SIGNATURE----- --Apple-Mail=_CDA7FB30-A3C4-449B-BCB9-FEF6EAC15A11-- From nobody Mon Jul 28 12:27:52 2014 Return-Path: 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 6D0CD1B28FA for ; Mon, 28 Jul 2014 12:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_PORT=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 d_0Fpzzn7POh for ; Mon, 28 Jul 2014 12:27:50 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B48F1B28F6 for ; Mon, 28 Jul 2014 12:27:50 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id h136so6455450oig.35 for ; Mon, 28 Jul 2014 12:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ac5L3Sl7k4iv6OuIV9etTTLdqT8iEhqXq3VhSDicAiE=; b=j4r5oUnLtFivI8fPv9mzWovKCrUbmxk1xp2Jiprlr/i5v2lZo1pbE3E53ogresZ1J1 m+7tgkhkWyGxmRVjRzesj+fguJCThyKBj/qipAENPZtTHTUqdpc+Txyq4cinrujCliph Gd5f3bsnwnSunMe8fxCDY7YLG3S3sH+kIz5viijWASIh5j5ccNB3Vv7P0FL1DYfxB6PC fHogj/SPCs+0+5LUH5+oSGyHT5ZW1aX+brhmFRQZAWCg/BBRVzqM8js3orJ6L2syxtO3 w7RXHe9rk7kR8PVSblB6FotrZT3/v88JDVlAE1tRx995ojxSNctRrTG/I5lWyKSuoQm4 1UMQ== MIME-Version: 1.0 X-Received: by 10.60.176.10 with SMTP id ce10mr52868757oec.8.1406575669594; Mon, 28 Jul 2014 12:27:49 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Mon, 28 Jul 2014 12:27:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Jul 2014 15:27:49 -0400 Message-ID: From: Dave Taht To: "Eggert, Lars" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/zXu-Wmwh7TOf4lIoMqAbZdItJQU Cc: rmcat WG Subject: Re: [rmcat] please check prelim minutes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:27:51 -0000 My comment was more like: David T: I expect the capacities mentioned in this draft are too small, say look at an asymmetric 5 Mbps upload/22mbit download case with a cable modem. The difference in bit-rate can be "interesting", especially when dealing with download traffic at this rate, you get a lot more acks in the pipe than you'd expect from a symmetric network. Changed in the text. I have a chart building up of common edge rates worth testing against, which I'll share when more baked. On Mon, Jul 28, 2014 at 7:31 AM, Eggert, Lars wrote: > Hi, > > please check and correct/expand our preliminary minutes from Toronto on h= ttp://etherpad.tools.ietf.org:9000/p/notes-ietf-90-rmcat?useMonospaceFont= =3Dtrue > > Thanks, > Lars --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Tue Jul 29 02:19:47 2014 Return-Path: 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 64BBC1A02DB for ; Tue, 29 Jul 2014 02:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 CQTftT4nkyms for ; Tue, 29 Jul 2014 02:19:43 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B1D1A00E7 for ; Tue, 29 Jul 2014 02:19:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,755,1400050800"; d="asc'?scan'208";a="137061761" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 29 Jul 2014 02:19:42 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht04-prd.hq.netapp.com (10.106.77.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Jul 2014 02:19:42 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 29 Jul 2014 02:19:38 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::45c1:c47:7b52:ae2%21]) with mapi id 15.00.0913.011; Tue, 29 Jul 2014 02:19:38 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: [rmcat] Summary of Toronto decisions Thread-Index: AQHPqAH0rgRtAY5g+k6S6YrWsx0gGJu3QcSA Date: Tue, 29 Jul 2014 09:19:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_F4B5C9C5-932C-4E60-862A-3A9F7662E1A1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/vR3EsXXBRgFLekDEix92jG37cbA Subject: Re: [rmcat] Summary of Toronto decisions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 09:19:44 -0000 --Apple-Mail=_F4B5C9C5-932C-4E60-862A-3A9F7662E1A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-7-25, at 14:14, Eggert, Lars wrote: > In the meantime, I wanted to summarize the decisions we took and = confirm them on the list: >=20 > * draft-perkins-rmcat-rtp-cc-feedback adopted as WG item > * draft-sarker-rmcat-eval-test adopted as WG item > * draft-zanaty-rmcat-app-interaction adopted as WG item >=20 > Please speak up if you disagree with these decisions. Please comment by Aug 8. Lars > Also, it became clear that we need additional meeting time in order to = take a look at the evaluation of the current candidates in more detail. = This will likely take more time than we can get during an IETF week. = There are a few options for us here: >=20 > * virtual interims (Webex) > * physical interim together with RTCWEB (if they happen to schedule = one soon) > * physical interim just for RMCAT > * long side meeting Sat or Sun in Honolulu >=20 > If you have a preference, please email rmcat-chairs@tools.ietf.org >=20 > Thanks, > Lars >=20 --Apple-Mail=_F4B5C9C5-932C-4E60-862A-3A9F7662E1A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU9dnKdZcnpRveo1xAQK1hwQAreBp034m8bPjWMTZr59PSoJJ9Pmk4P/q r+6E2UBAaI+0DuwyfYI5rjXcO4zFnmxH/I+U9ToMKQzJZSnDQTrzgslggtfw83pQ JyjvB7VcEtIyYPwpZ7zc3PPBi5CC0glcdq8+nbaCoRZ5j6go8KV2yjjcXe8ayfHt 4W3XAcKEtt0= =JdqA -----END PGP SIGNATURE----- --Apple-Mail=_F4B5C9C5-932C-4E60-862A-3A9F7662E1A1-- From nobody Wed Jul 30 13:47:40 2014 Return-Path: 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 2922F1A03F5; Wed, 30 Jul 2014 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jgl35P93wltr; Wed, 30 Jul 2014 13:47:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7F1A03B1; Wed, 30 Jul 2014 13:47:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> Date: Wed, 30 Jul 2014 13:47:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/aW0luc9g4qdERWneI1xSw4y5tgk Cc: rmcat@ietf.org Subject: [rmcat] Last Call: (Congestion Control Requirements For RMCAT) to Informational RFC X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:47:36 -0000 The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Congestion Control Requirements For RMCAT' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for realtime media congestion avoidance technique. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ballot/ No IPR declarations have been submitted directly on this I-D.