From nobody Mon Aug 4 09:17: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 C08BC1A03EB for ; Mon, 4 Aug 2014 09:17:43 -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, 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 9bTKjTJsfVCJ for ; Mon, 4 Aug 2014 09:17:37 -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 0458B1A0503 for ; Mon, 4 Aug 2014 09:17:30 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-6c-53dfb2184880 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.D0.04090.812BFD35; Mon, 4 Aug 2014 18:17:29 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.96]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Mon, 4 Aug 2014 18:17:28 +0200 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" Thread-Topic: SCReAM Questions, comments and answers Thread-Index: Ac+v67toGzBoGVtLRPKlIIR7Ckl9og== Date: Mon, 4 Aug 2014 16:17:28 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FAF769@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_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF769ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja7kpvvBBjs2c1qsvvmBzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGctfPGUueFtfsXrNDrYGxiV5XYycHBICJhLdF2eyQNhiEhfu rWfrYuTiEBI4yijRf3glI4SziFHi+szVbCBVbAI2EisPfQdKcHCICBhI3Ow1BQkzC1hJfDn+ lxnEFhbQl1jy5w6YLQK04M2SlWwQtp7E3jUHmUBsFgEViWXnbrGCjOEV8JVY/jAcJMwoICtx //s9FoiR4hK3nsxngrhNQGLJnvPMELaoxMvH/1ghbCWJFdsvMULU50ssO7UCzOYVEJQ4OfMJ ywRG4VlIRs1CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKFqcWlycm25k pJdalJlcXJyfp5eXWrKJERgpB7f8ttrBePC54yFGAQ5GJR7eBZH3g4VYE8uKK3MPMUpzsCiJ 8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6N/fvD5PIazsz+/N8/st5J93PRt9q4F ty5uu6RbvXDPp7/1c495aBot3b+o3cD+/uHy6zKPcyZxzpI963xJ7HHZg5NfLshu7ct4vy3r 0tknUUFBzxNrD72wDbZsTypnn5ZrF39NmHOnYdjWLxZJUTtYLI42fbhgPLniu+GmXerVM7et 5IrPc/mgxFKckWioxVxUnAgAj7CjGHUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/mdFa5zqaAxeBeJAl1hvcjg_4G00 Cc: Ingemar Johansson S Subject: [rmcat] SCReAM Questions, comments and answers 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, 04 Aug 2014 16:17:44 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF769ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi First of all, thanks for the comments to the SCReAM proposal during the RMC= AT session. Below I add some more info based on Piers's comments as well as= the comments that I see in the meeting minutes. + Intraprotocol fairness (Piers's comment) : A method very similar multipl= icative decrease is implemented in the SCReAM code that we use. In a few wo= rds it reduces CWND if the smoothed OWD exceeds half the target delay AND m= ore than 10 RTTs have elapsed since the last CWND reduction. This works so-= so but I needed to add another extra check that inhibits this function if t= he bitrate is low. + Media on hold or frame blanking (also related to Piers's comment): The id= ea is to avoid sending high bitrate media (video) for a short duration (~1 = RTT) and measure the OWD during this time. To aviod poor video performance = it is recommended to inhibit the video encoder during these periods as it m= akes it possible to maintain a correct codec state. This serves two purposes: 1) Make possible for the flow (as well as other intraprotocol flows) to mor= e correctly update their base delays, the rationale is that the queue occu= pancy in the bottleneck should drop to zero and then all intraprotocol flow= s should get a more correct base delay estimate. This solves the intraprot= ocol fairness issue quite well. 2) Detection of competing (TCP) flows and adjustment of delay target. If th= ere is only one flow then the OWD will drop to zero during the media on hol= d period otherwise OWD will have a higher value, the delay target is then s= et equal to the measured OWD. This is complemented by function which period= ically checks if the delay target can be decreased in the case that the com= peting flow is removed. Comment to what is written in the preliminary minutes. + Frame blanking and bursts: I am not sure that I understand the comment. T= he idea is to inhibit the video encoder for a short duration, the duration = is so short that the codec state and the congestion window is maintained as= is, in other words, no slow start is taking place. Now, because the predic= tion gain is reduced, there is a possibility that the PSNR may drop tempora= rly after a frame blanking period because of reduced prediction gain, curre= ntly I don't know exactly what the effect of frame blanking is. + 32 bits ACK vector: This was a design choise in the simulator. Currently = it is more than enough. It is however possible that RLE encoding over a lar= ger span is needed if the bitrates are higher and/or min RTT is larger. + Bytes in flight or packets in flight : I would recommend bytes in flight,= packets in flight can become messy as not all RTP packets use up the entir= e MTU, one example is if one IR frame is split into several RTP packets due= to MTU restrictions. + Dropping RTP packets : This should be avoided and used only as a last res= ort to remove RTP packets that are anyway too old to be rendered. It is ins= tead better to avoid encoding new RTP packets (frame skipping) as long as t= he sender queue is too larger, this helps to keep the video codec state in = a healthy condition. There may be other methods than frame skipping as Mo m= ention, the main point is that it should be possible to reduce the temporal= sender queue size growth in cases where the link thoughput drops. + Prediction in order to reduce jitter: I have tried out a method where the= video bitrate increase is slowed down around the last known congestion (in= flection) point. This is very similar to how TCP BIC or Cubic behaves, the = method increases the elapsed time between delay spikes but does not reduce = the size that much. In addition I implemented a 1st order prediction on the= OWD samples and use that as a trend indicator. This manages to remove almo= st all jitter spikes and for some unknown reason it improves the intra prot= ocol fairness greatly. There is more experimentation needed to make sure th= at it does work well with the LTE test cases. Probably missed a few comments/questions, please feel free to ask. Will add more details around the above in the next update of the draft. /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_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF769ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

First of all, thanks for the comments to the SCReAM = proposal during the RMCAT session. Below I add some more info based on Pier= s’s comments as well as the comments that I see in the meeting minute= s.

 

+ Intraprotocol fairness (Piers’s comment)=   : A method very similar multiplicative decrease is implemented in th= e SCReAM code that we use. In a few words it reduces CWND if the smoothed O= WD exceeds half the target delay AND more than 10 RTTs have elapsed since the last CWND reduction. This works so-so but I ne= eded to add another extra check that inhibits this function if the bitrate = is low.

 

+ Media on hold or frame blanking (also related = to Piers’s comment): The idea is to avoid sending high bitrate media = (video) for a short duration (~1 RTT) and measure the OWD during this time.= To aviod poor video performance it is recommended to inhibit the video encoder during these periods as it makes it possible = to maintain a correct codec state.

This serves two purposes:

1) Make possible for the flow (as well as other intr= aprotocol flows) to more correctly update their base delays, the rationale = is that  the queue occupancy in the bottleneck should drop to zero and= then all intraprotocol flows should get a  more correct base delay estimate. This solves the intraprotocol fa= irness issue quite well.     

2) Detection of competing (TCP) flows and adjustment= of delay target. If there is only one flow then the OWD will drop to zero = during the media on hold period otherwise OWD will have a higher value, the= delay target is then set equal to the measured OWD. This is complemented by function which periodically chec= ks if the delay target can be decreased in the case that the competing flow= is removed.

 

Comment to what is written in the preliminary minute= s.

 

+ Frame blanking and bursts: I am not sure that = I understand the comment. The idea is to inhibit the video encoder for a sh= ort duration, the duration is so short that the codec state and the congest= ion window is maintained as is, in other words, no slow start is taking place. Now, because the prediction gain is = reduced, there is a possibility that the PSNR may drop temporarly after a f= rame blanking period because of reduced prediction gain, currently I don= 217;t know exactly what the effect of frame blanking is.

+ 32 bits ACK vector: This was a design choise i= n the simulator. Currently it is more than enough. It is however possible t= hat RLE encoding over a larger span is needed if the bitrates are higher an= d/or min RTT is larger.

+ Bytes in flight or packets in flight : I would= recommend bytes in flight, packets in flight can become messy as not all R= TP packets use up the entire MTU, one example is if one IR frame is split i= nto several RTP packets due to MTU restrictions.

+ Dropping RTP packets : This should be avoided = and used only as a last resort to remove RTP packets that are anyway too ol= d to be rendered. It is instead better to avoid encoding new RTP packets (f= rame skipping) as long as the sender queue is too larger, this helps to keep the video codec state in a healthy condi= tion. There may be other methods than frame skipping as Mo mention, the mai= n point is that it should be possible to reduce the temporal sender queue s= ize growth in cases where the link thoughput drops.

+ Prediction in order to reduce jitter: I have t= ried out a method where the video bitrate increase is slowed down around th= e last known congestion (inflection) point. This is very similar to how TCP= BIC or Cubic behaves, the method increases the elapsed time between delay spikes but does not reduce the size that mu= ch. In addition I implemented a 1st order prediction on the OWD = samples and use that as a trend indicator. This manages to remove almost al= l jitter spikes and for some unknown reason it improves the intra protocol fairness greatly. There is more expe= rimentation needed to make sure that it does work well with the LTE test ca= ses.

 

Probably missed a few comments/questions, please fee= l free to ask.

 

Will add more details around the above in the next u= pdate of the draft.

 

/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_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF769ESESSMB205erics_-- From nobody Mon Aug 4 09:17: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 3D0D91A03EB for ; Mon, 4 Aug 2014 09:17:45 -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 jGkLAC7ysOjo for ; Mon, 4 Aug 2014 09:17:37 -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 9DDC61A0401 for ; Mon, 4 Aug 2014 09:17:30 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-9a-53dfb2173479 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.45.03739.712BFD35; Mon, 4 Aug 2014 18:17:28 +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; Mon, 4 Aug 2014 18:17:27 +0200 From: Ingemar Johansson S To: Piers O'Hanlon , Zaheduzzaman Sarker Thread-Topic: [iccrg] draft-johansson-rmcat-scream-cc Thread-Index: AQHPobGmDgx3xF9lZUi4Obdy1L0unJukku8wgAjqpwCAAGYaAIAA846AgBGJ5DA= Date: Mon, 4 Aug 2014 16:17:26 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31FAF764@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F9E116@ESESSMB205.ericsson.se> <9EA8AAC7-5986-49AD-83F7-EE5D71D51031@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31FAA290@ESESSMB205.ericsson.se> <190452F3-F173-418A-A545-A616796D63B7@gmail.com> <5563B4E8-D0F2-4C69-B34C-D6453ECCF774@gmail.com> In-Reply-To: <5563B4E8-D0F2-4C69-B34C-D6453ECCF774@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.150] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF764ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+Jvja7EpvvBBldu8VgcWLCT3WLfjImM FqtvfmBzYPbYOesuu8eSJT+ZPCZvPMwWwBzFZZOSmpNZllqkb5fAlTHhw1+WgkfLmCraVvaz NzC+bmDqYuTkkBAwkXgyeQk7hC0mceHeerYuRi4OIYGjjBINs1uZIJxFjBI3dhwA62ATsJFY eeg7I4gtIpAksfrbRGYQm1nAQeL41MVgNcJAU199nMEGUWMq8XbpWijbT2LD1w6wbSwCKhKn XvxiBbF5BXwlzk+dwgqx7B2TRPPtV2CDOAVsJU6dmgLWzCggK3H/+z0WiGXiEreezId6QUBi yZ7zzBC2qMTLx/9YIWwliRXbLzFC1OdLPDn1kw1imaDEyZlPWCYwis5CMmoWkrJZSMog4noS N6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMBY PLjlt+4OxtWvHQ8xCnAwKvHwLoi8HyzEmlhWXJl7iFGag0VJnHfRuXnBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhgZ1xyIDY42ZLaU5qv/1OjxfQrfqq2t4rG/J+32FfxlfmL2le3Jfw93 1VUs2O4mJve8sGyS375VBycY/vF8sMPq+vorun/Vt0hXBMsuXOFulBYXMGPurVtZYX7t7VsO vSrc3620tzbfpar6r89ktUajXfXr+ths01NVV5S4WZ1bJFi+d0/ptZ9KLMUZiYZazEXFiQA8 2r09pgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/zB88iJjnwuC6xi7wIeaQV7DjroE 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: Mon, 04 Aug 2014 16:17:45 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF764ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Piers Thanks for the pointer, for some reason I have missed this paper. I will address this as well as other comments in a separate email. /Ingemar From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com] Sent: den 24 juli 2014 11:03 To: Zaheduzzaman Sarker Cc: Ingemar Johansson S; iccrg@irtf.org; rmcat WG Subject: Re: [iccrg] draft-johansson-rmcat-scream-cc Hi Zahed, On 23 Jul 2014, at 19:31, Zaheduzzaman Sarker wrote: Hi Piers, Thanks for the comments. Could you please send us pointers to the research papers you mentioned in y= our reply regarding performance issue with "media on hold" in the wireline = network?. I was talking about the suggestions of related approaches such as the use o= f gaps (RFC6817 Sec 4.4) or 'Random window dropping' (section V.B) in "The = quest for LEDBAT fairness, Giovanna Carofiglio, Luca Muscariello, Dario Ros= si 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 f= lows. Piers 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_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF764ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Piers

 <= /p>

Thanks for the pointer, f= or some reason I have missed this paper.

I will address this as we= ll as other comments in a separate email.

 <= /p>

/Ingemar

 <= /p>

 <= /p>

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

 

Hi Zahed,

 

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



Hi Piers,

Thanks for the comments.<= /span>

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?.

 

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

 

Piers

 

 <= /p>

BR

 <= /p>

Zahed

 <= /p>

 <= /p>

From: Piers O'Hanlon [mailto:p.ohanlon@gmail.co= m] 
Sent: den 23 juli = 2014 08:26
To: Ingemar Johans= son S
Cc: Zaheduzzaman S= arker; iccrg@irtf.org; rmcat WG
Subject: Re: [iccr= g] 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>

From: Piers O'Hanlon [mailto:p.ohanlon@gmail.co= m] 
Sent: den 17 juli = 2014 13:24
To: Ingemar Johans= son S; Zaheduzzaman Sarker
Cc: iccrg@irtf.org; rmcat WG
Subject: Re: [iccr= g] 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>

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_81564C0D7D4D2A4B9A86C8C7404A13DA31FAF764ESESSMB205erics_-- From nobody Tue Aug 5 06:52:04 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 ABE4F1B27EA for ; Tue, 5 Aug 2014 06:52:01 -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 bW51pynWixpu for ; Tue, 5 Aug 2014 06:51: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 333AE1B27F6 for ; Tue, 5 Aug 2014 06:51:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,804,1400050800"; d="asc'?scan'208";a="138377680" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 05 Aug 2014 06:51:54 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 5 Aug 2014 06:51:47 -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.913.22; Tue, 5 Aug 2014 06:51:38 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::39bf:b832:59af:53b9%21]) with mapi id 15.00.0913.011; Tue, 5 Aug 2014 06:51:38 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org" Thread-Topic: IPR Disclosure: Polycom, Inc.'s Statement about IPR related to draft-singh-rmcat-adaptive-fec-00 Thread-Index: AQHPrbLE7yL0LpvGXE2yncWn9NHVNA== Date: Tue, 5 Aug 2014 13:51:36 +0000 Message-ID: <5703A19C-0B9D-4399-A2B3-C5F31818DAA9@netapp.com> References: <20140801180228.9948.64797.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.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_A61C4204-E8A2-47A8-9C56-A9CA4F903FDA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/G0hzgcr3Q-GMr9_xf6rg0TosIPA Subject: [rmcat] Fwd: IPR Disclosure: Polycom, Inc.'s Statement about IPR related to 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: Tue, 05 Aug 2014 13:52:01 -0000 --Apple-Mail=_A61C4204-E8A2-47A8-9C56-A9CA4F903FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: IETF Secretariat > Subject: IPR Disclosure: Polycom, Inc.'s Statement about IPR related = to draft-singh-rmcat-adaptive-fec-00 > Date: August 1, 2014 at 20:02:28 GMT+2 > 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-08-01 and has been posted on = the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2400/). The title of the IPR = disclosure is > "Polycom, Inc.'s Statement about IPR related to = draft-singh-rmcat-adaptive- > fec-00.""); >=20 > The IETF Secretariat >=20 --Apple-Mail=_A61C4204-E8A2-47A8-9C56-A9CA4F903FDA 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----- iQCVAwUBU+DhcNZcnpRveo1xAQIWZQP/eOc5ZKQl+Cd/yg+nbcQOsFFrrSllL0L5 8behkMZxdvYKLC5KtDLMMVdqWZ4kMwmLFmBi1GP+rMJgFwMExfjMV3PoNQkFoYr9 s2vhs5m2GNgzUgSFDWLl5v3k1yxJIbbaZVuM/ugPG7A3ecDIt0ITqYBupQYqdK8I 7/mFSKGNcow= =lsZy -----END PGP SIGNATURE----- --Apple-Mail=_A61C4204-E8A2-47A8-9C56-A9CA4F903FDA-- From mirja.kuehlewind@tik.ee.ethz.ch Wed Aug 6 05:06:50 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 370DE1B29AE for ; Wed, 6 Aug 2014 05:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 NRqhUplNHvSm for ; Wed, 6 Aug 2014 05:06:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A521A0299 for ; Wed, 6 Aug 2014 05:06:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6A09FD930B for ; Wed, 6 Aug 2014 14:06:43 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id P8GDQGbjLPc2 for ; Wed, 6 Aug 2014 14:06:43 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 32807D9302 for ; Wed, 6 Aug 2014 14:06:43 +0200 (MEST) Message-ID: <53E21A52.4090007@tik.ee.ethz.ch> Date: Wed, 06 Aug 2014 14:06:42 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rmcat@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Y75guQSCxBWFca7mjEs7PfOMykk Subject: [rmcat] New email address 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, 06 Aug 2014 13:06:08 -0000 Hi everybody, I changed jobs this week and therefore have a new email address. Please use the following address in future: mirja.kuehlewind@tik.ee.ethz.ch The old address is still active but I will check it less frequently over time. Thanks, Mirja From nobody Thu Aug 7 00:11:08 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 29D7A1B2846 for ; Thu, 7 Aug 2014 00:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 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_SOFTFAIL=0.665] 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 yJ24OmH6Jbiq for ; Thu, 7 Aug 2014 00:10:57 -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 C76DC1B27EE for ; Thu, 7 Aug 2014 00:10:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,816,1400050800"; d="asc'?scan'208";a="138758685" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 07 Aug 2014 00:10:57 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 7 Aug 2014 00:10:45 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 7 Aug 2014 00:10:44 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::39bf:b832:59af:53b9%21]) with mapi id 15.00.0913.011; Thu, 7 Aug 2014 00:10:32 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org" Thread-Topic: [ipr-announce] IPR Disclosure: Cisco's Statement of IPR Related to draft-zhu-rmcat-nada-03 Thread-Index: AQHPscFDrGJGdJ/roUi6R7nNgzdX2w== Date: Thu, 7 Aug 2014 07:10:32 +0000 Message-ID: <37FF5060-CD0E-4D7C-8EFB-8F068DFA562F@netapp.com> References: <20140806215627.17269.56900.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.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_3567A198-E7EC-4753-8E64-98CBD83EA4C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Hrsqf4U3Zd91Qe86neITWIJweB4 Subject: [rmcat] Fwd: [ipr-announce] IPR Disclosure: Cisco's Statement of IPR Related to draft-zhu-rmcat-nada-03 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, 07 Aug 2014 07:11:05 -0000 --Apple-Mail=_3567A198-E7EC-4753-8E64-98CBD83EA4C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: IETF Secretariat > Subject: [ipr-announce] IPR Disclosure: Cisco's Statement of IPR = Related to draft-zhu-rmcat-nada-03 > Date: August 6, 2014 at 23:56:27 GMT+2 > To: , > Cc: , >=20 >=20 > Dear Xiaoqing Zhu, Rong Pan: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled "NADA: = A > Unified Congestion Control Scheme for Real-Time Media" = (draft-zhu-rmcat-nada) > was submitted to the IETF Secretariat on 2014-08-06 and has been = posted on the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2409/). The title of the IPR = disclosure is > "Cisco's Statement of IPR Related to draft-zhu-rmcat-nada-03.""); >=20 > The IETF Secretariat >=20 > _______________________________________________ > ipr-announce mailing list > ipr-announce@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-announce --Apple-Mail=_3567A198-E7EC-4753-8E64-98CBD83EA4C6 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----- iQCVAwUBU+MmctZcnpRveo1xAQI79wP/b3Z2f23AN1K8yEzk7rUk7eMmyaFvpbmz V3KgtlO8R6EOzMLXR/nl0+h3O0/6OSONa4c1rJn2gXxNCVdBY2PZUnzVG2/BMEd/ oOe8S41JJxNwWIGsYqdndmvKsFDZLjhB0LQhAh6miNvQ5MFKxtHfh1OW8/LfuSZ/ eoo7IV9QHL4= =A1kQ -----END PGP SIGNATURE----- --Apple-Mail=_3567A198-E7EC-4753-8E64-98CBD83EA4C6-- From nobody Thu Aug 7 01:20: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 4FABF1B2994 for ; Thu, 7 Aug 2014 01:20:45 -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 Gm7m-9BEGpXi for ; Thu, 7 Aug 2014 01:20: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 7E5731B2993 for ; Thu, 7 Aug 2014 01:20:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,816,1400050800"; d="asc'?scan'208";a="138769807" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 07 Aug 2014 01:20:44 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 7 Aug 2014 01:20:31 -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.913.22; Thu, 7 Aug 2014 01:20:29 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::39bf:b832:59af:53b9%21]) with mapi id 15.00.0913.011; Thu, 7 Aug 2014 01:20:30 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: [rmcat] Summary of Toronto decisions Thread-Index: AQHPqAH0rgRtAY5g+k6S6YrWsx0gGJu3QcSAgA4UgAA= Date: Thu, 7 Aug 2014 08:20:29 +0000 Message-ID: <6E3F6D68-C2C0-4794-A5AF-9DC47CABDF5B@netapp.com> 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=_1452A232-E262-4269-87E4-32862DF5332D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/uL3IVp5ZQXOX_ANyMtVKe5ljvNU 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: Thu, 07 Aug 2014 08:20:45 -0000 --Apple-Mail=_1452A232-E262-4269-87E4-32862DF5332D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-7-29, at 11:19, 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. >=20 > Please comment by Aug 8. we've gotten additional support for these decisions by mail, with nobody = disagreeing, so these three drafts are now adopted as WG items. Editors, whenever you resubmit the next versions please change the names = to draft-rmcat-xyz-00. (You may wait with these resubmissions until you = have other edits to submit.) Lars --Apple-Mail=_1452A232-E262-4269-87E4-32862DF5332D 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----- iQCVAwUBU+M21tZcnpRveo1xAQKvngP/cy+Wwn8hGdiSuPM4EPTXq1szO8uLtYmS aMh44cAPugbklnFIJHMmFONpbPCBCifglB6B4Dn4xwJqbVf3P9RX9Y6+WS5k8HO5 AhPWs8rlwG7tUafKC+Sc+5loSXmlIBAR1PX+H24bdcH/Bc4VUUAw1q+TiDOAkeir EdmLXa6cWjw= =Q438 -----END PGP SIGNATURE----- --Apple-Mail=_1452A232-E262-4269-87E4-32862DF5332D-- From nobody Thu Aug 7 01:56:20 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 157E61B2A18; Thu, 7 Aug 2014 01:56:19 -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 j4HDsq9wuNmG; Thu, 7 Aug 2014 01:56:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A461B2A11; Thu, 7 Aug 2014 01:56:17 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807085617.26379.93813.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 01:56:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Ien78vcZsDHQx5qIIFUXywqjUYw Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-app-interaction-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, 07 Aug 2014 08:56:19 -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 : RTP Application Interaction with Congestion Control Authors : Mo Zanaty Varun Singh Suhas Nandakumar Zaheduzzaman Sarker Filename : draft-ietf-rmcat-app-interaction-00.txt Pages : 14 Date : 2014-08-07 Abstract: Interactive real-time media applications that use the Real-time Transport Protocol (RTP) over the User Datagram Protocol (UDP) must use congestion control techniques above the UDP layer since it provides none. This memo describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-app-interaction/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-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 Aug 7 02:29: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 0691A1B2A30; Thu, 7 Aug 2014 02:29:18 -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 SGAf9kze7Hmr; Thu, 7 Aug 2014 02:29:15 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EF21B2A29; Thu, 7 Aug 2014 02:29:15 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so4376413iec.16 for ; Thu, 07 Aug 2014 02:29:15 -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; bh=RK3nuhzeHY3fzuX+hTV/N4qkZSJxqRr15HQz1W169xA=; b=0OXtGqCzgOF06LVRME4MK0QwVkqs+2TbnGZfSYVkQj9pTit4fixthq1pykjEWkKXmq U/H9YOWn+bP6zLB3CMs2BDgJ39yg1FwrP2pGxsGxVc3dNKZUcoSX0IvEFpWDA6OxM5mA POhGKBDUa2YIzevqs1b3aauqfrjvQpQ72r51+xK+Zy54OW+HsuoVx9unPqH7cpkJEAX/ /fSvZcthAQTEy1C4/FkcBYt+uv6uq4car8cgwncyoXcEJywylOTyn3SvFxw6dYzTZ66l FlegHBrd7uT9/XLjr9Ql5XWoFT2e4f60N7E/wy7a4GcR7tKiU7L3Ph9ggYERxsxXCbxx K/8w== MIME-Version: 1.0 X-Received: by 10.42.201.134 with SMTP id fa6mr2186646icb.73.1407403755030; Thu, 07 Aug 2014 02:29:15 -0700 (PDT) Received: by 10.50.251.175 with HTTP; Thu, 7 Aug 2014 02:29:14 -0700 (PDT) Received: by 10.50.251.175 with HTTP; Thu, 7 Aug 2014 02:29:14 -0700 (PDT) In-Reply-To: <20140807085617.26379.93813.idtracker@ietfa.amsl.com> References: <20140807085617.26379.93813.idtracker@ietfa.amsl.com> Date: Thu, 7 Aug 2014 12:29:14 +0300 Message-ID: From: Varun Singh To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8488dfce38050006b82b Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/pgILfFccZ8inX9Rb5mEz3n6tUHs Cc: rmcat@ietf.org Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-app-interaction-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, 07 Aug 2014 09:29:18 -0000 --90e6ba6e8488dfce38050006b82b Content-Type: text/plain; charset=UTF-8 Hi, No changes were made, just submitted the last version of the document as the WG draft. -Varun On 7 Aug 2014 11:56, 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 : RTP Application Interaction with Congestion > Control > Authors : Mo Zanaty > Varun Singh > Suhas Nandakumar > Zaheduzzaman Sarker > Filename : draft-ietf-rmcat-app-interaction-00.txt > Pages : 14 > Date : 2014-08-07 > > Abstract: > Interactive real-time media applications that use the Real-time > Transport Protocol (RTP) over the User Datagram Protocol (UDP) must > use congestion control techniques above the UDP layer since it > provides none. This memo describes the interactions and conceptual > interfaces necessary between the application components that relate > to congestion control, including the RTP layer, the higher-level > media codec control layer, and the lower-level transport interface, > as well as components dedicated to congestion control functions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-app-interaction/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-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/ > > --90e6ba6e8488dfce38050006b82b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

No changes were made, just submitted the last version of the= document as the WG draft.

-Varun

On 7 Aug 2014 11:56, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the RTP Media Congestion Avoidance Techn= iques Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : RTP = Application Interaction with Congestion Control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mo Zanaty=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Varun Singh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Zaheduzzaman Sarker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-rmcat-app-interaction-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-08-07

Abstract:
=C2=A0 =C2=A0Interactive real-time media applications that use the Real-tim= e
=C2=A0 =C2=A0Transport Protocol (RTP) over the User Datagram Protocol (UDP)= must
=C2=A0 =C2=A0use congestion control techniques above the UDP layer since it=
=C2=A0 =C2=A0provides none. =C2=A0This memo describes the interactions and = conceptual
=C2=A0 =C2=A0interfaces necessary between the application components that r= elate
=C2=A0 =C2=A0to congestion control, including the RTP layer, the higher-lev= el
=C2=A0 =C2=A0media codec control layer, and the lower-level transport inter= face,
=C2=A0 =C2=A0as well as components dedicated to congestion control function= s.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-app= -interaction/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rmcat-app-interacti= on-00


Please note that it may take a couple of minutes from the time of submissio= n
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/

--90e6ba6e8488dfce38050006b82b-- From nobody Sat Aug 9 11:51:00 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 A593D1A0196; Sat, 9 Aug 2014 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] 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 vSQSEH-718yU; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C66561A0009; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s79ImD3G015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 13:48:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sat, 9 Aug 2014 13:48:13 -0500 X-Mao-Original-Outgoing-Id: 429302893.093861-e61d2b4180cda6697e5d18b3ca4c2570 Content-Transfer-Encoding: quoted-printable Message-Id: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: To: tsvwg@ietf.org, avt@ietf.org, "clue@ietf.org" , mmusic@ietf.org, rtcweb@ietf.org, rmcat@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/zacux4sSDv-iQSexURXIG1AG6jo Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: [rmcat] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 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: Sat, 09 Aug 2014 18:48:24 -0000 Hi, The DART working group has started a last call for = draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational = draft describes considerations for the use of DiffServ code points in = situations where one multiplexes multiple RTP packet streams, and = potentially other protocol streams, that share the same 5-tuple.=20 Since this draft is likely of interest to several working groups, I = would like to solicit additional reviews from participants of TSVWG, = AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback = (including feedback to the effect of "this is ready to progress") to the = DART working group mailing list. Thanks! Ben. Begin forwarded message: > Resent-From: draft-alias-bounces@tools.ietf.org > From: Ben Campbell > Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > Date: August 9, 2014 at 12:50:16 PM CDT > Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com > To: dart@ietf.org > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. = It's available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments = to the authors and the DART mailing list. If you've reviewed it and = think it's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 From nobody Tue Aug 12 16:57:00 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 65B841A0A8D; Tue, 12 Aug 2014 16:56:54 -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 mmvFOxsHpewP; Tue, 12 Aug 2014 16:56:52 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C8D1A079F; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id nu7so7848740obb.0 for ; Tue, 12 Aug 2014 16:56:51 -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=TvOMDq5bVsm7hrc0pMtqzJ3nCKU6PoaHcLOkO23aYxw=; b=Q2edh9KLW9eYpiJj7ynYizJxi2kDLXhA+WMrRGDFSwuWjFjw6l7ID0T4Cg4ifLYflI 9krQwPRmtajzhKepJRPiSlzdXx726KuTAfhsHatbGMn2PfyKAhIOjoWJ27DuD5y/A53P PbBoP81QEVdyfvvvWR+QdV0mYtj+A0i99lN7eVoE+OCrf6UcJ3EuE1I5sJw/CxQVrurK gV3yjCrAWpFCOV+tm+2rpCZZpgVDtgUDTu1gC4rdWCmoxN0AKcgu1WZGgiZm1gEsMV37 1KinnXCsG9qOV6vcurtE3jA6biqj7Ww9hH7tH+XHpMIS5p83eAeiKksRp4xThpJgT3y9 f1VQ== MIME-Version: 1.0 X-Received: by 10.60.74.104 with SMTP id s8mr1039793oev.5.1407887811135; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) In-Reply-To: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> Date: Tue, 12 Aug 2014 16:56:51 -0700 Message-ID: From: Dave Taht To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/_vPFbRlaL7K6eGc2G91hn_TzO8A Cc: mmusic@ietf.org, draft-ietf-dart-dscp-rtp.all@tools.ietf.org, "clue@ietf.org" , avt@ietf.org, "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rmcat] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 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, 12 Aug 2014 23:56:54 -0000 This is also of some interest to me at least, and perhaps some members of the AQM working group who are working out weighted fair queuing and wred like approaches to these needs. Anyway, I do try to track thinking in this area in the ongoing development of cerowrt's sqm system, which has pluggable modules for all the known aqm and fq schedulers, and a three tier system modeled on wondershaper for managing traffic, which uses what diffserv markings that I have observed make sense... Some relevant links: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt= _310 http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management Missing from this discussion so far is what is actually deployed out there... I am only familiar with stuff like the above as an egress/ingress queue management system... AND: in the case of linux based wireless routers, none of the AF codepoints are respected explicitly, and how the codepoints are mapped are described by 802.11e - and that is far more about scheduling priority for airtime rather than drop probability. It is kind of hard to wrap your head around how 802.11e actually works, but, this is a start: http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel= _access_.28EDCA.29 In linux wifi at least: CS0, CS3 are mapped into the BE hw queue CS1, CS2 are mapped into the BK hw queue CS4, CS5 are mapped into the VI hw queue CS6, CS7 are mapped into the VO hw queue Bit patterns for the other classes to whatever extent they map into CSX are mapped into the underlying hardware queue. I am not saying this is an optimal state of affairs, (as notably VO should be as completely disabled as possible in the 802.11n and ac age), and am very interested in how other OSes (ios, osx, windows), and router/switch OSes do it, but the wireless scheduling aspect of all these codepoints does not seem to be well touched upon. On a personal note I tend to think that having 17+ ways to slice up traffic is about 13 or 14 too many, particularly those targetting a drop probability. When you have drop rates well below a few percentage points, adding another percentage point of granularity seems futile. Lastly, there is also an implementation issue in linux presently in that doing extensive diffserv classification basically requires one iptables or tc rule per class, which is inefficient. Someone (not me!) doing some code for doing diffserv saner there would go a long way... On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell wrote: > Hi, > > The DART working group has started a last call for draft-ietf-dart-dscp-r= tp-02, ending on August 22. This informational draft describes consideratio= ns for the use of DiffServ code points in situations where one multiplexes = multiple RTP packet streams, and potentially other protocol streams, that s= hare the same 5-tuple. > > Since this draft is likely of interest to several working groups, I would= like to solicit additional reviews from participants of TSVWG, AVTCORE, MM= USIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback= to the effect of "this is ready to progress") to the DART working group ma= iling list. > > Thanks! > > Ben. > > Begin forwarded message: > >> Resent-From: draft-alias-bounces@tools.ietf.org >> From: Ben Campbell >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >> Date: August 9, 2014 at 12:50:16 PM CDT >> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com >> To: dart@ietf.org >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, Ric= hard Barnes >> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. I= t's available on the data tracker at the following URL: >> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >> >> The WGLC will conclude on 22 August, 2014. Please send your comments to = the authors and the DART mailing list. If you've reviewed it and think it's= good to go, please say so. >> >> Thanks! >> >> Ben. >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Thu Aug 14 13:14: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 740F91A0685; Thu, 14 Aug 2014 13:14:09 -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 O-7GR0n4JOJm; Thu, 14 Aug 2014 13:14:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 515D71A049E; Thu, 14 Aug 2014 13:14:08 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814201408.5584.43881.idtracker@ietfa.amsl.com> Date: Thu, 14 Aug 2014 13:14:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/w_55LCcBOIRXMrEsI7K_7iXQW0s Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-eval-test-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, 14 Aug 2014 20:14:09 -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 : Test Cases for Evaluating RMCAT Proposals Authors : Zaheduzzaman Sarker Varun Singh Xiaoqing Zhu Michael A. Ramalho Filename : draft-ietf-rmcat-eval-test-00.txt Pages : 36 Date : 2014-08-14 Abstract: The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications, these applications are typically required to implement congestion control. The RMCAT working group is currently working on candidate algorithms for such interactive real- time multimedia applications. This document describes the test cases to be used in the performance evaluation of those candidate algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-test/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-eval-test-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 Aug 14 13:28:14 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 24BEF1A06AB for ; Thu, 14 Aug 2014 13:28:12 -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 qqZPHOUHF9px for ; Thu, 14 Aug 2014 13:28:10 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C58A1A05E5 for ; Thu, 14 Aug 2014 13:28:10 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so36652igd.5 for ; Thu, 14 Aug 2014 13:28:09 -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=cVceqhCNLGyeqXEtf+1USZ40JjCKpCQ4MgxokwxN/T4=; b=XkC2uJFqaj7ma+avIoAxZc6B7Fk5bbnWVFM44hkMQuwBqnp7iYgyuSs1ycgK/BG36f SoWqykpEQAhZeqeqtRvgSZQ+YErlJrPdqwADBBpc6HQCsPsfpftIbWK5xvB9rAPu6S9M LphlWYvD4YItJ1YXmXAbv5k5C9Nm6glIJtjdeUp05X/42/DQawiRo45PuENQW/oEFbqy XxJznrr37cmbpHSHiW1lwzjNGnzFIFoQCLvS1zjSDajZUzbFHagSzoLTntlA7KyIi/WD BBYKGS//9LijVl0mBfseK2VCNnpweHbb9gi0qPtITChPrEqjXsp/9VqfEbriGf0QgS3P BrSw== X-Received: by 10.50.112.67 with SMTP id io3mr20075589igb.37.1408048089396; Thu, 14 Aug 2014 13:28:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.251.175 with HTTP; Thu, 14 Aug 2014 13:27:49 -0700 (PDT) In-Reply-To: <20140814201408.5584.43881.idtracker@ietfa.amsl.com> References: <20140814201408.5584.43881.idtracker@ietfa.amsl.com> From: Varun Singh Date: Thu, 14 Aug 2014 23:27:49 +0300 Message-ID: To: rmcat WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Xqwj48rSy8ALXsdOfsFDt1YF50g Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-eval-test-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, 14 Aug 2014 20:28:12 -0000 Hi all, No changes were made, this is a resubmission of the latest version of the individual document as a WG document. -Varun On Thu, Aug 14, 2014 at 11:14 PM, 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 : Test Cases for Evaluating RMCAT Proposals > Authors : Zaheduzzaman Sarker > Varun Singh > Xiaoqing Zhu > Michael A. Ramalho > Filename : draft-ietf-rmcat-eval-test-00.txt > Pages : 36 > Date : 2014-08-14 > > Abstract: > The Real-time Transport Protocol (RTP) is used to transmit media in > multimedia telephony applications, these applications are typically > required to implement congestion control. The RMCAT working group is > currently working on candidate algorithms for such interactive real- > time multimedia applications. This document describes the test cases > to be used in the performance evaluation of those candidate > algorithms. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-test/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-eval-test-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/ > -- http://www.netlab.tkk.fi/~varun/ From nobody Mon Aug 18 07:49: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 3D4261A048F; Mon, 18 Aug 2014 07:49:11 -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 Cj3-cpksvhQT; Mon, 18 Aug 2014 07:49:09 -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 4F6631A048E; Mon, 18 Aug 2014 07:49:09 -0700 (PDT) Received: from [130.209.247.112] (port=53640 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 1XJOF9-0005PK-4x; Mon, 18 Aug 2014 15:49:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 15:49:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> To: ietf@ietf.org 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/HMKdL7Xs6OY6113CS6RTS3Vcxw4 Cc: rmcat WG Subject: Re: [rmcat] Last Call: (Congestion Control Requirements For RMCAT) to Informational RFC 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, 18 Aug 2014 14:49:11 -0000 On 30 Jul 2014, at 21:47, The IESG wrote: > 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 >=20 > 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.=20 Apologies for the late response, but I have some extensive comments on = this draft: - Requirement 1A states that the congestion control algorithm should try = to keep delays to a minimum. I agree that this is a primary goal. = However, as I noted at IETF 90, I think the draft should also include a = secondary requirement to keep delay variation (jitter) down, where possible, = since larger delay variation needs larger receiver-side buffers to = compensate, increasing overall latency.=20 - Requirement 1B states that the algorithm should react "quickly" to any reduction in bandwidth or increase in delay. The draft needs to define what quickly means in this context, since the expected timing could be different to other congestion control algorithms. Is the expectation=20= that the response occurs with an RTT, or with next video frame, GoP, = or talkspurt? This comment also applies to requirements 1C, 1E, 1F, and = 4. - Requirement 1B uses an "increase in bottleneck delay" as a congestion signal, but it's not clear how the congestion control can distinguish = an increase in delay at the bottleneck from an increase in delay = elsewhere. Perhaps this should be =93an increase in observed delay=94? - Requirement 1C requires the congestion controller to react to = interface changes. Does this apply to changes in the local interface only, or to=20= changes in either the local or remote interface? One is a local = matter, while the other requires signalling, so the distinction may be = important. - Requirement 1D seems to describe possible behaviour of the system, but the requirement on the algorithm is not clear. Can you either clarify, or remove if there is no concrete requirement? - Requirement 1E states that "the algorithm must not overreact". Can you define (even approximately) what overreacting means in this context? Without this definition, it's not clear how this requirement could be translated into protocol behaviour. Similarly, what is "short-term"? - Requirement 1F states that the algorithm "must avoid too much delay=20 buildup during those bursts". This is, at least partly, outside the=20 control of the algorithm, since it depends on the behaviour of the cross traffic. Perhaps the requirement ought to be that the algorithm=20= does not significantly increase the delay buildup during the bursts? - Requirement 2 states that flows should get "roughly equal" shares of bandwidth, but gives no definition of =93roughly equal". I realise = that=20 this is a difficult issue, but some guidance, however approximate, = would be helpful.=20 - Requirement 2A is written in terms of "a useful share" of bandwidth. Again, defining "useful" would help: perhaps for the flow to ramp up = to=20 a bandwidth that allows it to support a minimal quality media stream? - Requirement 3A is unclear. Is the intent that there is no requirement that the algorithm compete equally with TCP flows that have different RTT? - Requirement 3B is unclear. Is the requirement that "the congestion control should prioritise achieving a useful (as defined in = Requirement 2A) share of the bandwidth over achieving as low as possible transit delay, when these two requirements are in conflict"? =20 - Requirements 4A, 4B, and 4C seem to describe possible behaviours of = the system, but the actual requirements are unclear. Requirment 4A could = be that the algorithm must reach a useful sending rate for audio calls = fast enough that the initial "Hello" is not clipped; it's not clear how = this applies to other media.=20 - Requirement 5 is for "stable" behaviour, but it is not clear what stability means with discontinuous transmission, since the media will have an on-off profile that is not stable.=20 - Requirement 5A lists possible behaviour for the algorithm, but it is = not clear what requirement is being placed on an implementation. It "may adapt more quickly", but is it required to do so? Previous bandwidth estimates "may need to be aged or thrown away", but are they required to be? - Requirement 6 could be interpreted as requiring general multipath congestion control. Is that the intent, or is the goal only to share information between flows between two endpoint when those flows share=20= a common bottleneck? - Requirement 6C gives a possible use for information, but it's not = clear what requirement is being placed on implementations. - Requirement 8 talks about mechanisms, using RTCP feedback and/or = header extensions. It's appropriate that this draft gives give general = feedback requirements, but I don't think it should be making explicit = requirements on how RTCP or RTP header extensions are used without justification,=20= especially since the RMCAT working group has a milestone to produce a draft giving such recommendations. I suggest keeping requirement 8E, but removing the rest of requirement 8. I also noted some editorial issues: - The RMCAT working group should have a limited lifetime. Accordingly,=20= the title might be better written as "Congestion Control Requirements for Interactive Real-time Media Transport=94? - The 4th paragraph of Section 1 talks about "requirements for RMCAT" = and "The RMCAT congestion control algorithm". I suggest these be changed = to "requirements for congestion control of interactive real-time media" = and "A congestion control algorithm for interactive real-time media". - The last paragraph of Section 1 states that terminology from the = WebRTC overview is used. This is appropriate. It might also be appropriate to align with draft-ietf-avtext-rtp-grouping-taxonomy and cite that = draft. - Requirement 1E talks about "short-term bursts (such as web-browsing)". This would be clearer if written "short-term bursts of competing = traffic (such as web browsing)", since the bursts are not due to the = congestion control algorithm. Colin --=20 Colin Perkins http://csperkins.org/ From nobody Tue Aug 19 16:17:42 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 D581A1A6FC1 for ; Tue, 19 Aug 2014 16:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 uZ_xLdHudxKb for ; Tue, 19 Aug 2014 16:17:39 -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 6E5D01A6FB2 for ; Tue, 19 Aug 2014 16:17:39 -0700 (PDT) Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54235 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJseo-0005Yt-3A; Tue, 19 Aug 2014 18:17:38 -0500 Message-ID: <53F3DAC4.1090707@jesup.org> Date: Tue, 19 Aug 2014 19:16:20 -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: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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/SbR2MJrrpDg4hikVVDTudxGpxlw Cc: Colin Perkins Subject: Re: [rmcat] Last Call: (Congestion Control Requirements For RMCAT) to Informational RFC 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, 19 Aug 2014 23:17:42 -0000 I'll preface my remarks with a paraphrase of the US Supreme Court: In many cases, I know something is X when I see it, but it's hard to put a written "X is " down, or the parameters of are fuzzy and multidimensional. In the end, the proposals will be evaluated by humans looking at all the data people can provide, turning it over in their heads, arguing, and saying "X is best" or "Y is best for XYZ usage, and Z is best for ABC usage". Kinda like "fairness".... That said, I'll dive in: On 8/18/2014 10:49 AM, Colin Perkins wrote: > On 30 Jul 2014, at 21:47, The IESG wrote: >> 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. > Apologies for the late response, but I have some extensive comments on this > draft: Thanks for looking at it closely. > - Requirement 1A states that the congestion control algorithm should try to > keep delays to a minimum. I agree that this is a primary goal. However, > as I noted at IETF 90, I think the draft should also include a secondary > requirement to keep delay variation (jitter) down, where possible, since > larger delay variation needs larger receiver-side buffers to compensate, > increasing overall latency. How about: Jitter (variation in the bitrate over short timescales) also is relevant, though moderate amounts of jitter will be absorbed by receiver jitter buffers. Transit delay should be considered to include the short-term maximums of delay including jitter. > - Requirement 1B states that the algorithm should react "quickly" to any > reduction in bandwidth or increase in delay. The draft needs to define > what quickly means in this context, since the expected timing could be > different to other congestion control algorithms. Is the expectation > that the response occurs with an RTT, or with next video frame, GoP, or > talkspurt? This comment also applies to requirements 1C, 1E, 1F, and 4. I'm loathe to give a hard number here, and instead leave that to the evaluation, since as with all things like this it's a tradeoff. I could state that "quickly" means a timescale on the order of RTT times (i.e. O(RTT)), and certainly well sub-second. (IMHO, a congestion mechanism needs to adapt down ASAP to avoid delay buildup it will then have to drain out). > - Requirement 1B uses an "increase in bottleneck delay" as a congestion > signal, but it's not clear how the congestion control can distinguish an > increase in delay at the bottleneck from an increase in delay elsewhere. > Perhaps this should be “an increase in observed delay”? Sure. > - Requirement 1C requires the congestion controller to react to interface > changes. Does this apply to changes in the local interface only, or to > changes in either the local or remote interface? One is a local matter, > while the other requires signalling, so the distinction may be important. I would say local interface changes should be noticed and both directions should take this into account if possible (for example as a sender by restarting adaptation from a known startpoint, or increase sensitivity/adaptation-rate temporarily in combination with an immediate drop in send rate as a precaution). On the receive side, it can indicate an interface change via RTCP, or just let the other side adapt if the bottleneck has changed. (Indicating a change may be preferable in order to more-intelligently adapt, but may not be required, and might not even help or help much.) Really I'm interested to see what the proposals find are the best way to handle this problem, without constricting the solution space. Suggested wording changes? > - Requirement 1D seems to describe possible behaviour of the system, but > the requirement on the algorithm is not clear. Can you either clarify, > or remove if there is no concrete requirement? Old: The offered load may be less than the available bandwidth at any given moment, and may vary dramatically over time, including dropping to no load and then resuming a high load, such as in a mute operation. The reaction time between a change in the bandwidth available from the algorithm and a change in the offered load is variable, and may be different when increasing versus decreasing. Proposal: The algorithm must deal with offered loads that are less than the available bandwidth at any given moment, and may vary dramatically over time, including dropping to no load and then resuming a high load, such as in a mute/unmute operation. Note that the reaction time between a change in the bandwidth available from the algorithm and a change in the offered load is variable, and may be different when increasing versus decreasing. i.e. make it into a requirement for the algorithm to deal with Mute operations and that offered load will not change immediately in response to the algorithm's idea of bandwidth (which was what was intended here). > - Requirement 1E states that "the algorithm must not overreact". Can you > define (even approximately) what overreacting means in this context? > Without this definition, it's not clear how this requirement could be > translated into protocol behaviour. Similarly, what is "short-term"? "the algorithm must deal with traffic bursts caused by actions such as webpage loading [by an aggressive browser/website combination]"? (with the part in [] being perhaps removable). Again, the definition of "quickly" comes into play. > - Requirement 1F states that the algorithm "must avoid too much delay > buildup during those bursts". This is, at least partly, outside the > control of the algorithm, since it depends on the behaviour of the > cross traffic. Perhaps the requirement ought to be that the algorithm > does not significantly increase the delay buildup during the bursts? Perhaps that's a good rewording; that's a tough/painful case since they may smoke your router's buffers regardless of what you do, so you may want to keep sending at a "normal" rate or close once the algorithm realizes it's lost the battle (temporarily). > - Requirement 2 states that flows should get "roughly equal" shares of > bandwidth, but gives no definition of “roughly equal". I realise that > this is a difficult issue, but some guidance, however approximate, would > be helpful. This is "fair" of course. I'm not sure how I can say much more without constraining the solution-space artificially. And it's worse because it's not a single-point measurement; defining it in detail would require looking at startup ramp, steady-state, reaction to BW changes and cross-traffic (does it remain "roughly equal"), etc. Down this road lives insanity... I can try alternate wiggle-words, or some additional somewhat-vague phrases. > - Requirement 2A is written in terms of "a useful share" of bandwidth. > Again, defining "useful" would help: perhaps for the flow to ramp up to > a bandwidth that allows it to support a minimal quality media stream? A "minimal quality media stream" may be 8Kbps (or less!) or it might be 8Mbps, so that makes it hard to define here.... > - Requirement 3A is unclear. Is the intent that there is no requirement > that the algorithm compete equally with TCP flows that have different > RTT? 3A says "don't be a hog" (likely not a problem anyways, but since once an algorithm has "given up" on low delay due to TCP competition you don't want it to starve the TCP streams by going CBR for example.) And for long-lived flows, it can't compete equally even with flows with the same RTT. > > - Requirement 3B is unclear. Is the requirement that "the congestion > control should prioritise achieving a useful (as defined in Requirement > 2A) share of the bandwidth over achieving as low as possible transit > delay, when these two requirements are in conflict"? That might be a nice way to state that, thanks. > - Requirements 4A, 4B, and 4C seem to describe possible behaviours of the > system, but the actual requirements are unclear. Requirment 4A could be > that the algorithm must reach a useful sending rate for audio calls fast > enough that the initial "Hello" is not clipped; it's not clear how this > applies to other media. Those were to push the solutions in the direction of having a reasonable start-of-call/stream behavior, which otherwise might get ignored and not looked at or optimized for. I agree they're somewhat editorial. > - Requirement 5 is for "stable" behaviour, but it is not clear what > stability means with discontinuous transmission, since the media will > have an on-off profile that is not stable. "must deal with"? > > - Requirement 5A lists possible behaviour for the algorithm, but it is not > clear what requirement is being placed on an implementation. It "may > adapt more quickly", but is it required to do so? Previous bandwidth > estimates "may need to be aged or thrown away", but are they required > to be? After stream resumption, the algorithm should attempt to regain a share of bandwidth as quickly as possible. ("useful share"?) *ducks* > - Requirement 6 could be interpreted as requiring general multipath > congestion control. Is that the intent, or is the goal only to share > information between flows between two endpoint when those flows share > a common bottleneck? The latter. I thought it was clear; wording suggestions? > - Requirement 6C gives a possible use for information, but it's not clear > what requirement is being placed on implementations. Right, it's editorial reminding them they can do that. > - Requirement 8 talks about mechanisms, using RTCP feedback and/or header > extensions. It's appropriate that this draft gives give general feedback > requirements, but I don't think it should be making explicit requirements > on how RTCP or RTP header extensions are used without justification, > especially since the RMCAT working group has a milestone to produce a > draft giving such recommendations. I suggest keeping requirement 8E, > but removing the rest of requirement 8. Ok. > > > I also noted some editorial issues: > > - The RMCAT working group should have a limited lifetime. Accordingly, > the title might be better written as "Congestion Control Requirements > for Interactive Real-time Media Transport”? Sure > > - The 4th paragraph of Section 1 talks about "requirements for RMCAT" and > "The RMCAT congestion control algorithm". I suggest these be changed to > "requirements for congestion control of interactive real-time media" and > "A congestion control algorithm for interactive real-time media". Sure > > - The last paragraph of Section 1 states that terminology from the WebRTC > overview is used. This is appropriate. It might also be appropriate to > align with draft-ietf-avtext-rtp-grouping-taxonomy and cite that draft. I think we can do that... (I'll see how much editing it needs to do so) > - Requirement 1E talks about "short-term bursts (such as web-browsing)". > This would be clearer if written "short-term bursts of competing traffic > (such as web browsing)", since the bursts are not due to the congestion > control algorithm. Sure. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Wed Aug 20 05:14:44 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 DAB8E1A02E4 for ; Wed, 20 Aug 2014 05:14:36 -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] 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 d3el8VQLXvvm for ; Wed, 20 Aug 2014 05:14:33 -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 599801A02D4 for ; Wed, 20 Aug 2014 05:14:33 -0700 (PDT) Received: from [130.209.247.112] (port=58866 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XK4mc-0006Pj-CN; Wed, 20 Aug 2014 13:14:31 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53F3DAC4.1090707@jesup.org> Date: Wed, 20 Aug 2014 13:14:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4BB899CF-C707-429B-A7EE-D5C7D11A8669@csperkins.org> References: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> <53F3DAC4.1090707@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/WlFTxtQRNj7J04H4suIaOdw4NdI Cc: rmcat@ietf.org Subject: Re: [rmcat] Last Call: (Congestion Control Requirements For RMCAT) to Informational RFC 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, 20 Aug 2014 12:14:37 -0000 Thanks - responses inline. Cheers, Colin On 20 Aug 2014, at 00:16, Randell Jesup wrote: > I'll preface my remarks with a paraphrase of the US Supreme Court: In = many cases, I know something is X when I see it, but it's hard to put a = written "X is " down, or the parameters of are fuzzy and = multidimensional. In the end, the proposals will be evaluated by humans = looking at all the data people can provide, turning it over in their = heads, arguing, and saying "X is best" or "Y is best for XYZ usage, and = Z is best for ABC usage". Kinda like =93fairness".... A lot of these are difficult to be precise about, I agree. > That said, I'll dive in: >=20 > On 8/18/2014 10:49 AM, Colin Perkins wrote: >> On 30 Jul 2014, at 21:47, The IESG wrote: >>> 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 >>>=20 >>> 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. >> Apologies for the late response, but I have some extensive comments = on this >> draft: >=20 > Thanks for looking at it closely. >=20 >> - Requirement 1A states that the congestion control algorithm should = try to >> keep delays to a minimum. I agree that this is a primary goal. = However, >> as I noted at IETF 90, I think the draft should also include a = secondary >> requirement to keep delay variation (jitter) down, where possible, = since >> larger delay variation needs larger receiver-side buffers to = compensate, >> increasing overall latency. >=20 > How about: > Jitter (variation in the bitrate over short timescales) > also is relevant, though moderate amounts of jitter will be > absorbed by receiver jitter buffers. Transit delay should be = considered > to include the short-term maximums of delay including = jitter. Sure. >> - Requirement 1B states that the algorithm should react "quickly" to = any >> reduction in bandwidth or increase in delay. The draft needs to = define >> what quickly means in this context, since the expected timing could = be >> different to other congestion control algorithms. Is the = expectation >> that the response occurs with an RTT, or with next video frame, = GoP, or >> talkspurt? This comment also applies to requirements 1C, 1E, 1F, = and 4. >=20 > I'm loathe to give a hard number here, and instead leave that to the = evaluation, since as with all things like this it's a tradeoff. I could = state that "quickly" means a timescale on the order of RTT times (i.e. = O(RTT)), and certainly well sub-second. (IMHO, a congestion mechanism = needs to adapt down ASAP to avoid delay buildup it will then have to = drain out). I agree that we don=92t want to give a hard number, but I think some = guidelines to set expectations would be useful. React within some small = multiple of the RTT would seem appropriate, possibly with some wording = about possible codec constraints also (e.g., react on the next video = frame, or maybe at the start of the next talk spurt)? Agree that = sub-second reaction is desirable.=20 Saying =93In this memo, a =91quick=92 reaction to congestion means=85=94 = would then cover the later uses of the term. >> - Requirement 1B uses an "increase in bottleneck delay" as a = congestion >> signal, but it's not clear how the congestion control can = distinguish an >> increase in delay at the bottleneck from an increase in delay = elsewhere. >> Perhaps this should be =93an increase in observed delay=94? >=20 > Sure. >=20 >> - Requirement 1C requires the congestion controller to react to = interface >> changes. Does this apply to changes in the local interface only, or = to >> changes in either the local or remote interface? One is a local = matter, >> while the other requires signalling, so the distinction may be = important. >=20 > I would say local interface changes should be noticed and both = directions should take this into account if possible (for example as a = sender by restarting adaptation from a known startpoint, or increase = sensitivity/adaptation-rate temporarily in combination with an immediate = drop in send rate as a precaution). On the receive side, it can = indicate an interface change via RTCP, or just let the other side adapt = if the bottleneck has changed. (Indicating a change may be preferable = in order to more-intelligently adapt, but may not be required, and might = not even help or help much.) >=20 > Really I=92m interested to see what the proposals find are the best = way to handle this problem, without constricting the solution space. Agree, and agree that those are likely mechanisms for doing this.=20 > Suggested wording changes? Maybe something like =93It should detect handover between different = interfaces (e.g., Wi-Fi to 3G) at sender or receiver, and signal these = to the congestion control algorithm where possible, to help the = algorithm respond quickly to such path changes=94?=20 >> - Requirement 1D seems to describe possible behaviour of the system, = but >> the requirement on the algorithm is not clear. Can you either = clarify, >> or remove if there is no concrete requirement? > Old: > The offered load may be less than the available bandwidth > at any given moment, and may vary dramatically over time, > including dropping to no load and then resuming a high load, > such as in a mute operation. The reaction time between a > change in the bandwidth available from the algorithm and a > change in the offered load is variable, and may be different > when increasing versus decreasing. >=20 > Proposal: > The algorithm must deal with offered loads that are less = than the available bandwidth > at any given moment, and may vary dramatically over time, > including dropping to no load and then resuming a high load, > such as in a mute/unmute operation. Note that the reaction = time between a > change in the bandwidth available from the algorithm and a > change in the offered load is variable, and may be different > when increasing versus decreasing. >=20 > i.e. make it into a requirement for the algorithm to deal with Mute = operations and that offered load will not change immediately in response = to the algorithm=92s idea of bandwidth (which was what was intended = here). Sure, makes sense. >> - Requirement 1E states that "the algorithm must not overreact". Can = you >> define (even approximately) what overreacting means in this = context? >> Without this definition, it's not clear how this requirement could = be >> translated into protocol behaviour. Similarly, what is = "short-term"? >=20 > "the algorithm must deal with traffic bursts caused by actions such as = webpage loading [by an aggressive browser/website combination]"? (with = the part in [] being perhaps removable). Again, the definition of = =93quickly" comes into play. Perhaps =93Short-term bursts of competing traffic (e.g., due to local = web browser use) can saturate a local bottleneck link, but also clear = quickly. The algorithm needs to be able respond quickly to such events = to help prevent queue build-up; it is desirable if it can also quickly = recover its sending rate when they conclude=94?=20 >> - Requirement 1F states that the algorithm "must avoid too much delay >> buildup during those bursts". This is, at least partly, outside the >> control of the algorithm, since it depends on the behaviour of the >> cross traffic. Perhaps the requirement ought to be that the = algorithm >> does not significantly increase the delay buildup during the = bursts? >=20 > Perhaps that=92s a good rewording; that's a tough/painful case since = they may smoke your router's buffers regardless of what you do, so you = may want to keep sending at a "normal" rate or close once the algorithm = realizes it's lost the battle (temporarily). Sure, it=92s difficult. If it=92s a transient burst that fills the queue = for a short time then disappears, then you want to back off to avoid = making the situation worse, then continue, but if the competing traffic = is determined to keep the queue full, you=92re better keeping sending = and accepting the latency, and let the user hang-up if it gets too bad. >> - Requirement 2 states that flows should get "roughly equal" shares = of >> bandwidth, but gives no definition of =93roughly equal". I realise = that >> this is a difficult issue, but some guidance, however approximate, = would >> be helpful. >=20 > This is "fair" of course. I'm not sure how I can say much more = without constraining the solution-space artificially. And it's worse = because it's not a single-point measurement; defining it in detail would = require looking at startup ramp, steady-state, reaction to BW changes = and cross-traffic (does it remain "roughly equal"), etc. Down this road = lives insanity=85 Of course. > I can try alternate wiggle-words, or some additional somewhat-vague = phrases. Add a =93It is difficult to give a definition of =91roughly equal=92 = because=85=94 to make it clear why the definition is imprecise? I=92m = less concerned that the definitions are vague, than that they=92re vague = without explanation of the factors that affect them. >> - Requirement 2A is written in terms of "a useful share" of = bandwidth. >> Again, defining "useful" would help: perhaps for the flow to ramp = up to >> a bandwidth that allows it to support a minimal quality media = stream? >=20 > A "minimal quality media stream" may be 8Kbps (or less!) or it might = be 8Mbps, so that makes it hard to define here=85. True, but the issue ought to be discussed. Quickly ramping up to get a = useful VoIP flow is straight-forward (as you say, 8kbps), but it=92s a = much harder problem for higher rate media. This draft should be setting = expectations that the ramp-up will take longer the higher your useful = rate, and that doesn=92t come across now. >> - Requirement 3A is unclear. Is the intent that there is no = requirement >> that the algorithm compete equally with TCP flows that have = different >> RTT? >=20 > 3A says "don't be a hog" (likely not a problem anyways, but since once = an algorithm has "given up" on low delay due to TCP competition you = don't want it to starve the TCP streams by going CBR for example.) And = for long-lived flows, it can=92t compete equally even with flows with = the same RTT. I got that from 3, but don=92t see how 3A adds to it. I=92d possibly = suggest removing 3A, since I think it=92s covered elsewhere in 2. >> - Requirement 3B is unclear. Is the requirement that "the congestion >> control should prioritise achieving a useful (as defined in = Requirement >> 2A) share of the bandwidth over achieving as low as possible = transit >> delay, when these two requirements are in conflict"? >=20 > That might be a nice way to state that, thanks. >=20 >> - Requirements 4A, 4B, and 4C seem to describe possible behaviours of = the >> system, but the actual requirements are unclear. Requirment 4A = could be >> that the algorithm must reach a useful sending rate for audio calls = fast >> enough that the initial "Hello" is not clipped; it's not clear how = this >> applies to other media. >=20 > Those were to push the solutions in the direction of having a = reasonable start-of-call/stream behavior, which otherwise might get = ignored and not looked at or optimized for. I agree they=92re somewhat = editorial. Pushing solutions in that direction makes sense, but to fit the way this = draft is structured as a set of requirements, I think these need to be = rephrased. >> - Requirement 5 is for "stable" behaviour, but it is not clear what >> stability means with discontinuous transmission, since the media = will >> have an on-off profile that is not stable. >=20 > =93must deal with"? Maybe, although might be better to just merge with 5A. >> - Requirement 5A lists possible behaviour for the algorithm, but it = is not >> clear what requirement is being placed on an implementation. It = "may >> adapt more quickly", but is it required to do so? Previous = bandwidth >> estimates "may need to be aged or thrown away", but are they = required >> to be? >=20 > After stream resumption, the algorithm should attempt to regain a = share of bandwidth as quickly as possible. > ("useful share"?) *ducks* =93After stream resumption, the algorithm should attempt to rapidly = regain its previous share of the bandwidth; the aggressiveness with = which this is done will decay with the length of the pause=94?? >> - Requirement 6 could be interpreted as requiring general multipath >> congestion control. Is that the intent, or is the goal only to = share >> information between flows between two endpoint when those flows = share >> a common bottleneck? >=20 > The latter. I thought it was clear; wording suggestions? =93across multiple RTP streams sent between two endpoints, when those = RTP streams share a common bottleneck, whether or not those streams are = multiplexed onto the same ports=94? >> - Requirement 6C gives a possible use for information, but it's not = clear >> what requirement is being placed on implementations. >=20 > Right, it=92s editorial reminding them they can do that. Sure, but it=92s in the requirements section, so needs to be phrased as = such. Suggest changing =93it should be possible for the application to = control=94 to =93the algorithm should allow the application to control=94 >> - Requirement 8 talks about mechanisms, using RTCP feedback and/or = header >> extensions. It's appropriate that this draft gives give general = feedback >> requirements, but I don't think it should be making explicit = requirements >> on how RTCP or RTP header extensions are used without = justification, >> especially since the RMCAT working group has a milestone to produce = a >> draft giving such recommendations. I suggest keeping requirement = 8E, >> but removing the rest of requirement 8. >=20 > Ok. >=20 >>=20 >>=20 >> I also noted some editorial issues: >>=20 >> - The RMCAT working group should have a limited lifetime. = Accordingly, >> the title might be better written as "Congestion Control = Requirements >> for Interactive Real-time Media Transport=94? >=20 > Sure >=20 >>=20 >> - The 4th paragraph of Section 1 talks about "requirements for RMCAT" = and >> "The RMCAT congestion control algorithm". I suggest these be = changed to >> "requirements for congestion control of interactive real-time = media" and >> "A congestion control algorithm for interactive real-time media". >=20 > Sure >=20 >>=20 >> - The last paragraph of Section 1 states that terminology from the = WebRTC >> overview is used. This is appropriate. It might also be appropriate = to >> align with draft-ietf-avtext-rtp-grouping-taxonomy and cite that = draft. >=20 > I think we can do that... (I'll see how much editing it needs to do = so) >=20 >> - Requirement 1E talks about "short-term bursts (such as = web-browsing)". >> This would be clearer if written "short-term bursts of competing = traffic >> (such as web browsing)", since the bursts are not due to the = congestion >> control algorithm. >=20 > Sure. >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Mon Aug 25 20:42:26 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 C12111A06FF for ; Mon, 25 Aug 2014 20:42:24 -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 OT14PYBO3gvD for ; Mon, 25 Aug 2014 20:42:22 -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 F115B1A06FB for ; Mon, 25 Aug 2014 20:42:21 -0700 (PDT) Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:64000 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XM7eG-0006QO-PQ for rmcat@ietf.org; Mon, 25 Aug 2014 22:42:20 -0500 Message-ID: <53FC01B2.8070502@jesup.org> Date: Mon, 25 Aug 2014 23:40:34 -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: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> <53F3DAC4.1090707@jesup.org> <4BB899CF-C707-429B-A7EE-D5C7D11A8669@csperkins.org> In-Reply-To: <4BB899CF-C707-429B-A7EE-D5C7D11A8669@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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/ozZ79S-1TU5YMCqgybsnpQKFIiY Subject: Re: [rmcat] Last Call: (Congestion Control Requirements For RMCAT) to Informational RFC 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, 26 Aug 2014 03:42:25 -0000 On 8/20/2014 8:14 AM, Colin Perkins wrote: > >>> - Requirement 1B states that the algorithm should react "quickly" to any >>> reduction in bandwidth or increase in delay. The draft needs to define >>> what quickly means in this context, since the expected timing could be >>> different to other congestion control algorithms. Is the expectation >>> that the response occurs with an RTT, or with next video frame, GoP, or >>> talkspurt? This comment also applies to requirements 1C, 1E, 1F, and 4. >> I'm loathe to give a hard number here, and instead leave that to the evaluation, since as with all things like this it's a tradeoff. I could state that "quickly" means a timescale on the order of RTT times (i.e. O(RTT)), and certainly well sub-second. (IMHO, a congestion mechanism needs to adapt down ASAP to avoid delay buildup it will then have to drain out). > I agree that we don’t want to give a hard number, but I think some guidelines to set expectations would be useful. React within some small multiple of the RTT would seem appropriate, possibly with some wording about possible codec constraints also (e.g., react on the next video frame, or maybe at the start of the next talk spurt)? Agree that sub-second reaction is desirable. > > Saying “In this memo, a ‘quick’ reaction to congestion means…” would then cover the later uses of the term. Ok, I'll do that. > >>> - Requirement 1B uses an "increase in bottleneck delay" as a congestion >>> signal, but it's not clear how the congestion control can distinguish an >>> increase in delay at the bottleneck from an increase in delay elsewhere. >>> Perhaps this should be “an increase in observed delay”? >> Sure. >> >>> - Requirement 1C requires the congestion controller to react to interface >>> changes. Does this apply to changes in the local interface only, or to >>> changes in either the local or remote interface? One is a local matter, >>> while the other requires signalling, so the distinction may be important. >> I would say local interface changes should be noticed and both directions should take this into account if possible (for example as a sender by restarting adaptation from a known startpoint, or increase sensitivity/adaptation-rate temporarily in combination with an immediate drop in send rate as a precaution). On the receive side, it can indicate an interface change via RTCP, or just let the other side adapt if the bottleneck has changed. (Indicating a change may be preferable in order to more-intelligently adapt, but may not be required, and might not even help or help much.) >> >> Really I’m interested to see what the proposals find are the best way to handle this problem, without constricting the solution space. > Agree, and agree that those are likely mechanisms for doing this. > >> Suggested wording changes? > Maybe something like “It should detect handover between different interfaces (e.g., Wi-Fi to 3G) at sender or receiver, and signal these to the congestion control algorithm where possible, to help the algorithm respond quickly to such path changes”? Ok, I'll come up with something like that. > >>> - Requirement 1E states that "the algorithm must not overreact". Can you >>> define (even approximately) what overreacting means in this context? >>> Without this definition, it's not clear how this requirement could be >>> translated into protocol behaviour. Similarly, what is "short-term"? >> "the algorithm must deal with traffic bursts caused by actions such as webpage loading [by an aggressive browser/website combination]"? (with the part in [] being perhaps removable). Again, the definition of “quickly" comes into play. > Perhaps “Short-term bursts of competing traffic (e.g., due to local web browser use) can saturate a local bottleneck link, but also clear quickly. The algorithm needs to be able respond quickly to such events to help prevent queue build-up; it is desirable if it can also quickly recover its sending rate when they conclude”? That sounds pretty good, thanks > >>> - Requirement 1F states that the algorithm "must avoid too much delay >>> buildup during those bursts". This is, at least partly, outside the >>> control of the algorithm, since it depends on the behaviour of the >>> cross traffic. Perhaps the requirement ought to be that the algorithm >>> does not significantly increase the delay buildup during the bursts? >> Perhaps that’s a good rewording; that's a tough/painful case since they may smoke your router's buffers regardless of what you do, so you may want to keep sending at a "normal" rate or close once the algorithm realizes it's lost the battle (temporarily). > Sure, it’s difficult. If it’s a transient burst that fills the queue for a short time then disappears, then you want to back off to avoid making the situation worse, then continue, but if the competing traffic is determined to keep the queue full, you’re better keeping sending and accepting the latency, and let the user hang-up if it gets too bad. Right. Maybe I'll combine your original and some of that. > >>> - Requirement 2 states that flows should get "roughly equal" shares of >>> bandwidth, but gives no definition of “roughly equal". I realise that >>> this is a difficult issue, but some guidance, however approximate, would >>> be helpful. >> This is "fair" of course. I'm not sure how I can say much more without constraining the solution-space artificially. And it's worse because it's not a single-point measurement; defining it in detail would require looking at startup ramp, steady-state, reaction to BW changes and cross-traffic (does it remain "roughly equal"), etc. Down this road lives insanity… > Of course. > >> I can try alternate wiggle-words, or some additional somewhat-vague phrases. > Add a “It is difficult to give a definition of ‘roughly equal’ because…” to make it clear why the definition is imprecise? I’m less concerned that the definitions are vague, than that they’re vague without explanation of the factors that affect them. Sure, sounds good. > >>> - Requirement 2A is written in terms of "a useful share" of bandwidth. >>> Again, defining "useful" would help: perhaps for the flow to ramp up to >>> a bandwidth that allows it to support a minimal quality media stream? >> A "minimal quality media stream" may be 8Kbps (or less!) or it might be 8Mbps, so that makes it hard to define here…. > True, but the issue ought to be discussed. Quickly ramping up to get a useful VoIP flow is straight-forward (as you say, 8kbps), but it’s a much harder problem for higher rate media. This draft should be setting expectations that the ramp-up will take longer the higher your useful rate, and that doesn’t come across now. Ok, how about "a useful share of the bandwidth" and "A useful share will depend on the media types involved and total bandwidth available, but should allow reasonable communication quickly assuming similar media types and required bandwidths". Also, it's more about the existing flows ramping down fast enough so that the new flow (which will likely start at a "reasonable minimum" bandwidth) doesn't cause all the flows to start seeing delay and/or loss. Likely applications using this will lower-limit the bandwidth and when forced down there will live with extra delay (i.e. the compete with greedy TCP case), and if delay is egregious or if loss builds up badly as well then it may decide to drop that stream or indicate connection failure. >>> - Requirement 3A is unclear. Is the intent that there is no requirement >>> that the algorithm compete equally with TCP flows that have different >>> RTT? >> 3A says "don't be a hog" (likely not a problem anyways, but since once an algorithm has "given up" on low delay due to TCP competition you don't want it to starve the TCP streams by going CBR for example.) And for long-lived flows, it can’t compete equally even with flows with the same RTT. > I got that from 3, but don’t see how 3A adds to it. I’d possibly suggest removing 3A, since I think it’s covered elsewhere in 2. ok > >>> - Requirements 4A, 4B, and 4C seem to describe possible behaviours of the >>> system, but the actual requirements are unclear. Requirment 4A could be >>> that the algorithm must reach a useful sending rate for audio calls fast >>> enough that the initial "Hello" is not clipped; it's not clear how this >>> applies to other media. >> Those were to push the solutions in the direction of having a reasonable start-of-call/stream behavior, which otherwise might get ignored and not looked at or optimized for. I agree they’re somewhat editorial. > Pushing solutions in that direction makes sense, but to fit the way this draft is structured as a set of requirements, I think these need to be rephrased. I'll take a shot at that. > >>> - Requirement 5 is for "stable" behaviour, but it is not clear what >>> stability means with discontinuous transmission, since the media will >>> have an on-off profile that is not stable. >> “must deal with"? > Maybe, although might be better to just merge with 5A. > >>> - Requirement 5A lists possible behaviour for the algorithm, but it is not >>> clear what requirement is being placed on an implementation. It "may >>> adapt more quickly", but is it required to do so? Previous bandwidth >>> estimates "may need to be aged or thrown away", but are they required >>> to be? >> After stream resumption, the algorithm should attempt to regain a share of bandwidth as quickly as possible. >> ("useful share"?) *ducks* > “After stream resumption, the algorithm should attempt to rapidly regain its previous share of the bandwidth; the aggressiveness with which this is done will decay with the length of the pause”?? That's better. (I'd say "may decay" or "should decay" to avoid hard-restricting the solutions). > >>> - Requirement 6 could be interpreted as requiring general multipath >>> congestion control. Is that the intent, or is the goal only to share >>> information between flows between two endpoint when those flows share >>> a common bottleneck? >> The latter. I thought it was clear; wording suggestions? > “across multiple RTP streams sent between two endpoints, when those RTP streams share a common bottleneck, whether or not those streams are multiplexed onto the same ports”? ok > >>> - Requirement 6C gives a possible use for information, but it's not clear >>> what requirement is being placed on implementations. >> Right, it’s editorial reminding them they can do that. > Sure, but it’s in the requirements section, so needs to be phrased as such. Suggest changing “it should be possible for the application to control” to “the algorithm should allow the application to control” ok -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Aug 26 02:48: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 7BB101A6F03 for ; Tue, 26 Aug 2014 02:48:20 -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] 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 ld3sPsvKzzVX for ; Tue, 26 Aug 2014 02:48:13 -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 B44741A6F07 for ; Tue, 26 Aug 2014 02:48:12 -0700 (PDT) Received: from [130.209.247.112] (port=55055 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 1XMDMC-00011p-IR; Tue, 26 Aug 2014 10:48:06 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53FC01B2.8070502@jesup.org> Date: Tue, 26 Aug 2014 10:48:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90089AE7-77F8-4228-B680-A6AF484E6EBF@csperkins.org> References: <20140730204733.28360.91386.idtracker@ietfa.amsl.com> <53F3DAC4.1090707@jesup.org> <4BB899CF-C707-429B-A7EE-D5C7D11A8669@csperkins.org> <53FC01B2.8070502@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/gfEuezjmGPbiOGmAao3Dg4AX3dI Cc: rmcat@ietf.org Subject: Re: [rmcat] Last Call: (Congestion Control Requirements For RMCAT) to Informational RFC 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, 26 Aug 2014 09:48:21 -0000 Hi Randell, That all sounds good - thanks! Colin On 26 Aug 2014, at 04:40, Randell Jesup wrote: > On 8/20/2014 8:14 AM, Colin Perkins wrote: >>=20 >>>> - Requirement 1B states that the algorithm should react "quickly" = to any >>>> reduction in bandwidth or increase in delay. The draft needs to = define >>>> what quickly means in this context, since the expected timing = could be >>>> different to other congestion control algorithms. Is the = expectation >>>> that the response occurs with an RTT, or with next video frame, = GoP, or >>>> talkspurt? This comment also applies to requirements 1C, 1E, 1F, = and 4. >>> I'm loathe to give a hard number here, and instead leave that to the = evaluation, since as with all things like this it's a tradeoff. I could = state that "quickly" means a timescale on the order of RTT times (i.e. = O(RTT)), and certainly well sub-second. (IMHO, a congestion mechanism = needs to adapt down ASAP to avoid delay buildup it will then have to = drain out). >> I agree that we don=92t want to give a hard number, but I think some = guidelines to set expectations would be useful. React within some small = multiple of the RTT would seem appropriate, possibly with some wording = about possible codec constraints also (e.g., react on the next video = frame, or maybe at the start of the next talk spurt)? Agree that = sub-second reaction is desirable. >>=20 >> Saying =93In this memo, a =91quick=92 reaction to congestion means=85=94= would then cover the later uses of the term. >=20 > Ok, I'll do that. >=20 >>=20 >>>> - Requirement 1B uses an "increase in bottleneck delay" as a = congestion >>>> signal, but it's not clear how the congestion control can = distinguish an >>>> increase in delay at the bottleneck from an increase in delay = elsewhere. >>>> Perhaps this should be =93an increase in observed delay=94? >>> Sure. >>>=20 >>>> - Requirement 1C requires the congestion controller to react to = interface >>>> changes. Does this apply to changes in the local interface only, = or to >>>> changes in either the local or remote interface? One is a local = matter, >>>> while the other requires signalling, so the distinction may be = important. >>> I would say local interface changes should be noticed and both = directions should take this into account if possible (for example as a = sender by restarting adaptation from a known startpoint, or increase = sensitivity/adaptation-rate temporarily in combination with an immediate = drop in send rate as a precaution). On the receive side, it can = indicate an interface change via RTCP, or just let the other side adapt = if the bottleneck has changed. (Indicating a change may be preferable = in order to more-intelligently adapt, but may not be required, and might = not even help or help much.) >>>=20 >>> Really I=92m interested to see what the proposals find are the best = way to handle this problem, without constricting the solution space. >> Agree, and agree that those are likely mechanisms for doing this. >>=20 >>> Suggested wording changes? >> Maybe something like =93It should detect handover between different = interfaces (e.g., Wi-Fi to 3G) at sender or receiver, and signal these = to the congestion control algorithm where possible, to help the = algorithm respond quickly to such path changes=94? >=20 > Ok, I'll come up with something like that. >=20 >>=20 >>>> - Requirement 1E states that "the algorithm must not overreact". = Can you >>>> define (even approximately) what overreacting means in this = context? >>>> Without this definition, it's not clear how this requirement = could be >>>> translated into protocol behaviour. Similarly, what is = "short-term"? >>> "the algorithm must deal with traffic bursts caused by actions such = as webpage loading [by an aggressive browser/website combination]"? = (with the part in [] being perhaps removable). Again, the definition of = =93quickly" comes into play. >> Perhaps =93Short-term bursts of competing traffic (e.g., due to local = web browser use) can saturate a local bottleneck link, but also clear = quickly. The algorithm needs to be able respond quickly to such events = to help prevent queue build-up; it is desirable if it can also quickly = recover its sending rate when they conclude=94? >=20 > That sounds pretty good, thanks >=20 >>=20 >>>> - Requirement 1F states that the algorithm "must avoid too much = delay >>>> buildup during those bursts". This is, at least partly, outside = the >>>> control of the algorithm, since it depends on the behaviour of = the >>>> cross traffic. Perhaps the requirement ought to be that the = algorithm >>>> does not significantly increase the delay buildup during the = bursts? >>> Perhaps that=92s a good rewording; that's a tough/painful case since = they may smoke your router's buffers regardless of what you do, so you = may want to keep sending at a "normal" rate or close once the algorithm = realizes it's lost the battle (temporarily). >> Sure, it=92s difficult. If it=92s a transient burst that fills the = queue for a short time then disappears, then you want to back off to = avoid making the situation worse, then continue, but if the competing = traffic is determined to keep the queue full, you=92re better keeping = sending and accepting the latency, and let the user hang-up if it gets = too bad. >=20 > Right. Maybe I'll combine your original and some of that. >=20 >>=20 >>>> - Requirement 2 states that flows should get "roughly equal" shares = of >>>> bandwidth, but gives no definition of =93roughly equal". I = realise that >>>> this is a difficult issue, but some guidance, however = approximate, would >>>> be helpful. >>> This is "fair" of course. I'm not sure how I can say much more = without constraining the solution-space artificially. And it's worse = because it's not a single-point measurement; defining it in detail would = require looking at startup ramp, steady-state, reaction to BW changes = and cross-traffic (does it remain "roughly equal"), etc. Down this road = lives insanity=85 >> Of course. >>=20 >>> I can try alternate wiggle-words, or some additional somewhat-vague = phrases. >> Add a =93It is difficult to give a definition of =91roughly equal=92 = because=85=94 to make it clear why the definition is imprecise? I=92m = less concerned that the definitions are vague, than that they=92re vague = without explanation of the factors that affect them. >=20 > Sure, sounds good. >=20 >>=20 >>>> - Requirement 2A is written in terms of "a useful share" of = bandwidth. >>>> Again, defining "useful" would help: perhaps for the flow to ramp = up to >>>> a bandwidth that allows it to support a minimal quality media = stream? >>> A "minimal quality media stream" may be 8Kbps (or less!) or it might = be 8Mbps, so that makes it hard to define here=85. >> True, but the issue ought to be discussed. Quickly ramping up to get = a useful VoIP flow is straight-forward (as you say, 8kbps), but it=92s a = much harder problem for higher rate media. This draft should be setting = expectations that the ramp-up will take longer the higher your useful = rate, and that doesn=92t come across now. >=20 > Ok, how about "a useful share of the bandwidth" and "A useful share = will depend on the media types involved and total bandwidth available, = but should allow reasonable communication quickly assuming similar media = types and required bandwidths". Also, it's more about the existing = flows ramping down fast enough so that the new flow (which will likely = start at a "reasonable minimum" bandwidth) doesn't cause all the flows = to start seeing delay and/or loss. Likely applications using this will = lower-limit the bandwidth and when forced down there will live with = extra delay (i.e. the compete with greedy TCP case), and if delay is = egregious or if loss builds up badly as well then it may decide to drop = that stream or indicate connection failure. >=20 >>>> - Requirement 3A is unclear. Is the intent that there is no = requirement >>>> that the algorithm compete equally with TCP flows that have = different >>>> RTT? >>> 3A says "don't be a hog" (likely not a problem anyways, but since = once an algorithm has "given up" on low delay due to TCP competition you = don't want it to starve the TCP streams by going CBR for example.) And = for long-lived flows, it can=92t compete equally even with flows with = the same RTT. >> I got that from 3, but don=92t see how 3A adds to it. I=92d possibly = suggest removing 3A, since I think it=92s covered elsewhere in 2. >=20 > ok >=20 >>=20 >>>> - Requirements 4A, 4B, and 4C seem to describe possible behaviours = of the >>>> system, but the actual requirements are unclear. Requirment 4A = could be >>>> that the algorithm must reach a useful sending rate for audio = calls fast >>>> enough that the initial "Hello" is not clipped; it's not clear = how this >>>> applies to other media. >>> Those were to push the solutions in the direction of having a = reasonable start-of-call/stream behavior, which otherwise might get = ignored and not looked at or optimized for. I agree they=92re somewhat = editorial. >> Pushing solutions in that direction makes sense, but to fit the way = this draft is structured as a set of requirements, I think these need to = be rephrased. >=20 > I'll take a shot at that. >=20 >>=20 >>>> - Requirement 5 is for "stable" behaviour, but it is not clear what >>>> stability means with discontinuous transmission, since the media = will >>>> have an on-off profile that is not stable. >>> =93must deal with"? >> Maybe, although might be better to just merge with 5A. >>=20 >>>> - Requirement 5A lists possible behaviour for the algorithm, but it = is not >>>> clear what requirement is being placed on an implementation. It = "may >>>> adapt more quickly", but is it required to do so? Previous = bandwidth >>>> estimates "may need to be aged or thrown away", but are they = required >>>> to be? >>> After stream resumption, the algorithm should attempt to regain a = share of bandwidth as quickly as possible. >>> ("useful share"?) *ducks* >> =93After stream resumption, the algorithm should attempt to rapidly = regain its previous share of the bandwidth; the aggressiveness with = which this is done will decay with the length of the pause=94?? >=20 > That's better. (I'd say "may decay" or "should decay" to avoid = hard-restricting the solutions). >=20 >>=20 >>>> - Requirement 6 could be interpreted as requiring general multipath >>>> congestion control. Is that the intent, or is the goal only to = share >>>> information between flows between two endpoint when those flows = share >>>> a common bottleneck? >>> The latter. I thought it was clear; wording suggestions? >> =93across multiple RTP streams sent between two endpoints, when those = RTP streams share a common bottleneck, whether or not those streams are = multiplexed onto the same ports=94? >=20 > ok >=20 >>=20 >>>> - Requirement 6C gives a possible use for information, but it's not = clear >>>> what requirement is being placed on implementations. >>> Right, it=92s editorial reminding them they can do that. >> Sure, but it=92s in the requirements section, so needs to be phrased = as such. Suggest changing =93it should be possible for the application = to control=94 to =93the algorithm should allow the application to = control=94 >=20 > ok >=20 >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Fri Aug 29 02:31: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 75F251A06FB for ; Fri, 29 Aug 2014 02:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 5NFIL0ogelvB for ; Fri, 29 Aug 2014 02:31:35 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7104A1A06ED for ; Fri, 29 Aug 2014 02:31:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0E445D9310; Fri, 29 Aug 2014 11:31:33 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aAOCMBpGzR1T; Fri, 29 Aug 2014 11:31:32 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f718cd7.pool.mediaWays.net [95.113.140.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B59C9D930B; Fri, 29 Aug 2014 11:31:32 +0200 (MEST) Message-ID: <54004874.9030500@tik.ee.ethz.ch> Date: Fri, 29 Aug 2014 11:31:32 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rmcat@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/IyMwDSk26icealtMJIbrETmA6U0 Cc: Karen Elisabeth Egede Nielsen , "Eggert, Lars" Subject: [rmcat] Physical interim meeting (in Zurich or Munich) 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, 29 Aug 2014 09:31:37 -0000 Hi w-g, as discussed at the last meeting, we would like to hold an intermin meeting. We propose a physical meeting beginning of October. This will probably be a meeting with two half days, so people can fly in in the morning and leave the next afternoon/evening. There are two options. We can choose whichever is more suitable for most of the people: * Zurich, Oct 8/9 (at ETH in the city center) * Munich, between 6-9 (at NetApp, 20 Minutes out of the city but good train connection) Please let us know as soon as possible if you would be able to attend (and which date would be best for you). If we get a sufficient number of replies we will set up the logistics next. Thanks, your chairs From nobody Fri Aug 29 06:05:22 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 7B0791A0304 for ; Fri, 29 Aug 2014 06:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 n-OsLnFXZCLV for ; Fri, 29 Aug 2014 06:05:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C761F1A0307 for ; Fri, 29 Aug 2014 06:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1398AD930B; Fri, 29 Aug 2014 15:05:09 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4bE6aVc6p0cM; Fri, 29 Aug 2014 15:05:08 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f718cd7.pool.mediaWays.net [95.113.140.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AD6FFD930A; Fri, 29 Aug 2014 15:05:08 +0200 (MEST) Message-ID: <54007A83.4080904@tik.ee.ethz.ch> Date: Fri, 29 Aug 2014 15:05:07 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <54004874.9030500@tik.ee.ethz.ch> In-Reply-To: <54004874.9030500@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/agXsYn26KdhHrJwpJ7p2KqqsR0A Cc: Karen Elisabeth Egede Nielsen , "Eggert, Lars" Subject: Re: [rmcat] Physical interim meeting (in Zurich or Munich) 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, 29 Aug 2014 13:05:21 -0000 Hi agian, just to clarify the dates; sorry if this was confusing * Zurich: Oct 8/9 (fixed) * Munich: one or two days the same week between Oct 6 and Oct 9 Mirja On 29.08.2014 11:31, Mirja Kühlewind wrote: > Hi w-g, > > as discussed at the last meeting, we would like to hold an intermin > meeting. We propose a physical meeting beginning of October. This will > probably be a meeting with two half days, so people can fly in in the > morning and leave the next afternoon/evening. There are two options. We > can choose whichever is more suitable for most of the people: > > * Zurich, Oct 8/9 (at ETH in the city center) > > * Munich, between 6-9 (at NetApp, 20 Minutes out of the city but good > train connection) > > Please let us know as soon as possible if you would be able to attend > (and which date would be best for you). If we get a sufficient number of > replies we will set up the logistics next. > > Thanks, > your chairs > > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------