Subject: [Iccrg] Fwd: [R-C] Fwd: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada
From: [email-masked] (Michael Welzl)
Date: Wed May 23 23:21:54 2012

Begin forwarded message:

> From: Harald Alvestrand <[email-masked]>
> Date: May 23, 2012 8:11:00 PM GMT+02:00
> To: "[email-masked]" <[email-masked]>
> Subject: [R-C] Fwd: Call for Papers: IAB/IRTF Workshop on Congestion  
> Control for Interactive Real-Time Communication, July 28, 2012  
> Vancouver, Canada
>
> Here's the CFP. Yes, the date is fixed now.
>
> -------- Original Message --------
> Subject:	Call for Papers: IAB/IRTF Workshop on Congestion Control  
> for Interactive Real-Time Communication, July 28, 2012 Vancouver,  
> Canada
> Date:	Wed, 23 May 2012 10:47:49 -0700
> From:	IAB Chair <[email-masked]>
> Reply-To:	[email-masked]
> Organization:	Internet Architecture Board
> To:	<[email-masked]>
> CC:	[email-masked]
>
>
> IAB / IRTF Workshop on
> Congestion Control for Interactive
> Real-Time Communication
> July 28, 2012
> Vancouver, Canada
>
> The IAB and IRTF will hold a workshop on Congestion Control for  
> Interactive Real-Time Communication" in Vancouver, Canada on  
> Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html) 
> .  Participation at the workshop is free of charge. There is no  
> requirement to either register with or attend the IETF-84 meeting  
> that follows the workshop.
>
> The workshop organizers would like to foster a discussion on:
> What are appropriate congestion signals to use for interactive media  
> and data?
> What existing congestion control algorithms are appropriate for  
> interactive media and data? What properties would be desirable in  
> new congestion control algorithms?
> Measurement and/or simulations of new congestion signals (e.g.,  
> delay-based) and their interaction with existing congestion control  
> mechanisms.
> What are good available techniques for adjusting sending rates for  
> interactive media and data? What are the limits of those techniques?  
> What properties would be desirable in new techniques?
> What application-specific considerations have to be taken into  
> account?
> How can we ensure that real-time communications are well-behaved  
> with respect to other Internet applications while still providing  
> good quality?
> What should the IETF and/or IRTF do?
> The organizers seek position papers on any or all of these topics,  
> as well as other topics related to congestion control for  
> interactive realtime media.
>
> Every prospective workshop participant must submit a position paper  
> containing a name and an email address. Authors of accepted papers  
> will be invited to the workshop. Papers up to 3 pages, formatted in  
> HTML, PDF, or plain text (for example, as a submitted Internet- 
> Draft) are ideal. Accepted position papers will be published.   
> Additional details about the meeting venue will be provided to  
> authors of accepted papers.
> Important Dates
>
> Position paper submission deadline:          June 23, 2012
> Notification to paper authors:                       June 30, 2012
> Workshop date:                                             July 28,  
> 2012
> Additional Details
>
> Additional details on the workshop as well as the submission process  
> is available at http://www.iab.org/cc-workshop/
> Contact
>
> To sponsors: If you are interested to help us working towards better  
> interactive media congestion control mechanisms on the Internet  
> (such as by making a contribution towards catering costs and room  
> rental), please contact us!
>
> In case of questions please send email to mary.ietf.barnes at  
> gmail.com.
>
> _______________________________________________
> Rtp-congestion mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120524/9242be50/attachment.html
>From [email-masked]  Thu May 31 12:51:29 2012
From: [email-masked] (Michael Welzl)
Date: Thu May 31 12:50:47 2012
Subject: [Iccrg] Meeting in Vancouver
Message-ID: <[email-masked]>

Hi,

We have requested a slot at the Vancouver IETF. If you want to give a 
talk, please send us the title and how much time you'd like to have.

Cheers,
Michael

From: [email-masked] (David Ros)
Date: Mon May 21 14:40:28 2012
Subject: [Iccrg] [rtcweb] Hold the date: Trying to get a workshop on  congestion control for real time interactive media together....
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 21 mai 2012, at 14:10, ken carlberg wrote:

> it would nice if some form of audio/jabber session could be set up for those that won't be able to attend.
> 

+1

Thanks,

David.

> -ken
> 
> 
> On May 21, 2012, at 8:00 AM, Eggert, Lars wrote:
> 
>> FYI
>> 
>> It is likely that the IRTF will co-sponsor this event, since congestion control has been one of our long-running research topics.
>> 
>> Lars
>> 
>> Begin forwarded message:
>> 
>>> From: Harald Alvestrand <[email-masked]>
>>> Subject: [rtcweb] Hold the date: Trying to get a workshop on congestion control for real time interactive media together....
>>> Date: May 19, 2012 15:46:39 GMT+02:00
>>> To: "[email-masked]" <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
>>> 
>>> FYI ... .the IAB is trying to get together a workshop (of the typical IAB format; people get invited if they contribute ideas beforehand) together before the Vancouver IETF, covering the same subject area as the RTP congestion work.
>>> 
>>> This would have a goal, among other things, of getting people to think about the subject matter for our BOF/WG, and get people better informed (and interested!) before the BOF.
>>> 
>>> The likely date is Saturday before the IETF (July 28), but this is not settled yet, so don't book tickets specifically for this until you hear the official announcement....
>>> 
>>>           Harald
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

"It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett

From: [email-masked] (Eggert, Lars)
Date: Tue May  8 16:13:24 2012
Subject: [Iccrg] Fwd: [tcpm] "Controlling Queue Delay" published.
References: <[email-masked]>
Message-ID: <[email-masked]>

Probably of interest

Begin forwarded message:

> From: Jim Gettys <[email-masked]>
> Subject: [tcpm] "Controlling Queue Delay" published.
> Date: May 8, 2012 8:15:54 EDT
> To: "[email-masked]'" <[email-masked]>
> 
> Kathie Nichols and Van Jacobson published a new adaptive AQM algorithm today, which, we think, provides the missing piece to solve bufferbloat (rather than just mitigate the problem).
> 
> See: http://queue.acm.org/detail.cfm?id=2209336
> 
> I wrote a blog article to set a bit more context for a more general audience than tcpm at:
> 
> http://gettys.wordpress.com/2012/05/08/fundamental-progress-solving-bufferbloat/
> 
> Patches for Linux are available.
> 					- Jim
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120508/dbf62a0b/smime.bin
>From [email-masked]  Wed May  9 21:48:30 2012
From: [email-masked] (sebastien.jobert)
Date: Wed May  9 21:42:53 2012
Subject: [Iccrg] ECN marking over wireless networks
Message-ID: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1>

Hi,

There has been some discussion during the IETF 83 in Paris in ICCRG and CONEX WG about relevant ECN marking algorithms over wireless networks.

Some aspects related to this topic are discussed in this draft: http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf, briefly introduced during ICCRG meeting.

This email aims at starting some discussion on the mailing lists of ICCRG and CONEX, as requested by the chairs after the discussions during IETF 83.

Essentially, the main aspect pointed out during the discussions was that there might benefits in taking into account the radio conditions of the mobile terminal for ECN marking over the radio segment and for congestion-volume counting. The reason for this is that it requires more radio resources to transmit the same amount of data to a terminal in bad radio conditions compared to a terminal in good radio conditions.

As an introduction to the discussion, it might be useful to mention that different potential use cases for ECN marking involving the mobile terminal could be envisaged:

1.       interaction with TCP

2.       adapt the coding rate of adaptive application (e.g. adaptive streaming, etc.), as suggested in 3GPP TS 36.300 document

3.       stop/delay the non-urgent applications (background tasks in the terminal, etc.)

4.       congestion-volume counting (as for Conex related use cases)

This list is obviously non-exhaustive, and shows that depending on the final utilization of the congestion notification, different algorithms for ECN marking over the radio segment might be imagined. The most optimal algorithm certainly depends on the final objective.

>From the comments received during the discussion, it seems that the first ECN marking algorithm over the radio segment that comes to most people's mind is to consider an average queue length exceeding a given threshold, as for RED. It should be noted that because the radio segment shares the radio resource among several terminals, one dedicated queue per terminal is in general considered.

Therefore, if one would like to apply RED over a wireless segment, it should be clarified whether it would be applied independently on each dedicated queue per terminal (n instances of RED considered for the radio segment), or on the sum of all the dedicated queues (1 single instance of RED considered for the radio segment). This would lead to two different ECN marking criteria:

1.       RED based on the individual queue of each terminal

2.       RED based on a single shared queue between all the terminals

Several remarks were raised during the presentation of the draft in ICCRG and the discussion in CONEX:

-          On the interactions with TCP (use case #1 listed above), it was mentioned that TCP works on a longer timescale relative to the wireless channel. In other words: the radio conditions may vary more quickly than TCP reactions. This is correct, however, it should be mentioned that the objective of ECN marking over the radio segment is not to replace the existing radio schedulers, which already provide a suitable control loop over these shorter time scales. As an example, the very common Proportional Fair (PF) algorithm aims at addressing exactly this point, by trying to optimize the allocation of radio resources (the terminals in good instantaneous radio conditions are favored compared to the others, as to optimize the cell capacity, while certain fairness is ensured in the longer term by taking into account also the averaged throughputs delivered to the terminals).

-          Still regarding the interactions with TCP (use case #1 listed above), assume now that a PF algorithm is used to control the allocation of radio resources. It was mentioned also that if it is assumed that ECN marking is done according to the individual queue of each terminal (criteria #1 listed above), then a terminal in bad radio conditions will already experience ECN marking more often without the need to weight the probability of the ECN marking with the radio conditions of the terminal. This is due to the fact that PF provides higher throughput to terminals in good averaged radio conditions than in bad averaged radio conditions. Actually, the amount of ECN marking will depend in this case whether the throughput required to transmit the data to a particular terminal is lower than the throughput provided to this terminal by PF; if not, then no ECN marking should happen for this terminal in these conditions (even during congested periods actually). 

-          Based on this discussion, it seems to me that the interaction of ECN marking with TCP should not be analyzed in terms of benefits it brings to control the allocation of resources over the radio segment, which is already under the control of the radio scheduler. It seems that this second control loop provided by ECN marking interacting with TCP would rather aim at indicating when the traffic rate of a terminal exceeds the throughput provided by PF to this terminal, which could be useful for use case #2 (coding rate adaptation). Basically, it is expected that this second control loop would try to "align" with the throughput provided by the first one (keeping in mind that PF provides throughputs varying with time).

-          The same example but now with the ECN marking criteria #2 instead of #1 raises however issues. Indeed, in case the throughput required to transmit the data to one particular terminal is lower than the throughput provided to this terminal, this will lead to ECN marking for all the terminals, even the ones below the PF throughput, which is a situation that should be avoided when interaction with TCP is desirable. Excessive traffic consumption on one terminal should not impact the others (i.e. should not lead to the generation of ECN marking for the others). Definitely, the criteria #1 does not seem a good idea when interaction with TCP is desired.

-          Considering the use case #3 depicted earlier now, it should be noted however that the previous situation with PF + ECN marking based on individual queues (criteria #1) has some limitation. Indeed, in case of radio congestion (assume here that radio congestion means that all the radio resources are used and are not enough to transmit all the data to be transmitted to all the terminals - a more accurate definition might be found), some of the terminals may not received ECN marking, as indicated before (in case they require less than what PF can provide to them). Perhaps some of the data transmitted to these non-notified terminals are not so critical and might be delayed, as to free resources to the other users with more important traffic to be exchanged. The depicted situation does not provide incentives to do this, because ECN marking only applies to some users. It is the reason why it might be interesting to consider other ECN marking algorithms (which might not aim at interacting necessarily with TCP; BTW not all the applications are running over TCP), as to inform about the congestion situation. The idea is to say to the end user: "Hey! The system starts being full, the PF algorithm will still provide you with some network resources, but if some of your data can be delayed, please do so!" Of course, this kind of approach might be coupled with congestion-volume counting / CONEX use cases, to provide incentives.

-          Let's take a practical example to illustrate (note sure it is the best one, but it is the one that comes to my mind...): you need to go to some administration to collect some administrative document - say, a voting card to elect your new president. There is already a long queue, but you could pass with a "certain priority" because what you need to do is faster than what other people have to do. However, if you collect your document, you consume resources of the system that will not be available to the others during this time - the person in front of you will be busy giving you your document. And what you need to do is not urgent - the election is not tomorrow, you will have time to come back later. Perhaps you would like to be fair with the other people having more urgent things to do and waiting in the queue, and you will not wait and instead come back later? And perhaps a signal indicating the congestion might be useful (it is probably good to know if the queue is long or not, rather than waiting without information).

-          Considering the use case #4 depicted earlier now on congestion-volume counting: it seems logical to me that the count would take into account the real network resource usage rather than simply the number of bits transmitted. This would provide again incentives to users in bad radio conditions to delay non-urgent network usage. Moreover, an interesting question which should be raised would be to define what corresponds to a "congested period" for the radio segment: is it only when the terminal exceeds its PF rate, or should a congestion period be considered when the system starts being full/is full? This might trigger different ECN marking algorithms on the wireless segment. 

I had noted two other comments from the discussions in IETF 83:

-          TCP middlebox accelerating TCP window growth: some comment was made on the mic, however I am not sure that I understood what this device is supposed to do; would anyone of you have some reference on this?

-          Retransmission over the radio segment: should it be taken into account as well for congestion-volume counting? It would mean that a lost packet that is retransmitted by the low layers should be counted twice? (after all, if it was retransmitted by TCP, it would have been counted twice as well, right?)

Feedback on this discussion is welcomed. Thanks in advance.

Cheers,

S?bastien JOBERT
Orange Expert "Future Networks", network synchronization and QoS in mobile networks
Orange Labs, Networks & Carriers - France Telecom R&D
[email-masked] <mailto:[email-masked]>  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120509/594feaaf/attachment-0001.html
>From [email-masked]  Mon May 21 13:00:04 2012
From: [email-masked] (Eggert, Lars)
Date: Mon May 21 12:53:50 2012
Subject: [Iccrg] Fwd: [rtcweb] Hold the date: Trying to get a workshop on
 congestion control for real time interactive media together....
References: <[email-masked]>
Message-ID: <[email-masked]>

FYI

It is likely that the IRTF will co-sponsor this event, since congestion control has been one of our long-running research topics.

Lars

Begin forwarded message:

> From: Harald Alvestrand <[email-masked]>
> Subject: [rtcweb] Hold the date: Trying to get a workshop on congestion control for real time interactive media together....
> Date: May 19, 2012 15:46:39 GMT+02:00
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> FYI ... .the IAB is trying to get together a workshop (of the typical IAB format; people get invited if they contribute ideas beforehand) together before the Vancouver IETF, covering the same subject area as the RTP congestion work.
> 
> This would have a goal, among other things, of getting people to think about the subject matter for our BOF/WG, and get people better informed (and interested!) before the BOF.
> 
> The likely date is Saturday before the IETF (July 28), but this is not settled yet, so don't book tickets specifically for this until you hear the official announcement....
> 
>             Harald
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120521/3a972c7e/smime.bin
>From [email-masked]  Mon May 21 13:10:53 2012
From: [email-masked] (ken carlberg)
Date: Mon May 21 13:03:43 2012
Subject: [Iccrg] [rtcweb] Hold the date: Trying to get a workshop on 
	congestion control for real time interactive media together....
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

it would nice if some form of audio/jabber session could be set up for those that won't be able to attend.

-ken

On May 21, 2012, at 8:00 AM, Eggert, Lars wrote:

> FYI
> 
> It is likely that the IRTF will co-sponsor this event, since congestion control has been one of our long-running research topics.
> 
> Lars
> 
> Begin forwarded message:
> 
>> From: Harald Alvestrand <[email-masked]>
>> Subject: [rtcweb] Hold the date: Trying to get a workshop on congestion control for real time interactive media together....
>> Date: May 19, 2012 15:46:39 GMT+02:00
>> To: "[email-masked]" <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>> 
>> FYI ... .the IAB is trying to get together a workshop (of the typical IAB format; people get invited if they contribute ideas beforehand) together before the Vancouver IETF, covering the same subject area as the RTP congestion work.
>> 
>> This would have a goal, among other things, of getting people to think about the subject matter for our BOF/WG, and get people better informed (and interested!) before the BOF.
>> 
>> The likely date is Saturday before the IETF (July 28), but this is not settled yet, so don't book tickets specifically for this until you hear the official announcement....
>> 
>>            Harald
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg