Subject: [Iccrg] Re: Timely reaction time (Re: [R-C] Comments on draft-alvestrand-rtcweb-congestion-01)
From: [email-masked] (Michael Welzl)
Date: Fri Mar 30 11:17:05 2012

On Mar 30, 2012, at 10:33 AM, Harald Alvestrand wrote:

> On 03/29/2012 01:55 PM, Michael Welzl wrote:
>>
>>
>>> Section 4: par 3, "This algorithm is run every time a receive  
>>> report arrives..." => so in case of severe congestion, when  
>>> nothing else arrives, this algorithm waits for 2 *  
>>> t_max_fb_interval... so can we rely on the mechanism to react to  
>>> this congestion after roughly an RTO or not? (sounds like not)  Is  
>>> that bad?  (I guess)
>>>
>>> There is a need for some emergency break mechanism if no feedback  
>>> gets through.
>>
>> I totally agree - what I meant is, it isn't clear to me if that  
>> emergency break is activated in time or too late. It should be in  
>> time (i.e. after roughly an RTO).
> This seems to be a subject that should be discussed in the context  
> of the circuit-breakers draft: What kind of response time is  
> appropriate for such a mechanism, and why?

I think not: we're talking about two kinds of situations here. The  
context here is: there was congestion, we should react to it within an  
RTO (and have an "emergency break" to always do that - but maybe that  
term was misleading). The circuit-breakers draft is about a much more  
serious condition (such as persistent congestion), warranting a much  
more serious reaction (terminating the connection).

Cheers,
Michael

From: [email-masked] (Harald Alvestrand)
Date: Fri Mar 30 09:32:37 2012
Subject: [Iccrg] Timely reaction time (Re: [R-C] Comments on  draft-alvestrand-rtcweb-congestion-01)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <CAEdus3L3Ovsnh5hrteh4tw9n-=[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 03/29/2012 01:55 PM, Michael Welzl wrote:
>
>
>> Section 4: par 3, "This algorithm is run every time a receive report 
>> arrives..." => so in case of severe congestion, when nothing else 
>> arrives, this algorithm waits for 2 * t_max_fb_interval... so can we 
>> rely on the mechanism to react to this congestion after roughly an 
>> RTO or not? (sounds like not)  Is that bad?  (I guess)
>>
>> There is a need for some emergency break mechanism if no feedback 
>> gets through.
>
> I totally agree - what I meant is, it isn't clear to me if that 
> emergency break is activated in time or too late. It should be in time 
> (i.e. after roughly an RTO). 
This seems to be a subject that should be discussed in the context of 
the circuit-breakers draft: What kind of response time is appropriate 
for such a mechanism, and why?

The current draft proposes that we're OK with a reaction time of around 
10 seconds for a mechanism that we expect to use only in "emergencies" 
(such as total channel failure) - on the basis that getting a faster 
reaction time would require too much redesign of other parts of the 
ecosystem.

As long as we can assume we get feedback signals in a timely fashion, we 
can take the absence of signals as a sign for "continue as usual", so 
the "emergency brake" is something we need when we have a total 
breakdown of the feedback channel, not for "day-to-day control".

I think a discussion on what the timing requirements for an emergency 
brake are is a Good thing - but it may belong on AVTCORE rather than here.

From: [email-masked] (Piers O'Hanlon)
Date: Thu Mar 29 13:15:44 2012
Subject: [Iccrg] Re: [R-C] Comments on draft-alvestrand-rtcweb-congestion-01
In-Reply-To: <CAEdus3L3Ovsnh5hrteh4tw9n-=[email-masked]>
References: <[email-masked]> <CAEdus3L3Ovsnh5hrteh4tw9n-=[email-masked]>
Message-ID: <[email-masked]>

Hi Stefan,

On 29 Mar 2012, at 13:32, Stefan Holmer wrote:

> Hi Michael,
> 
> On Wed, Mar 28, 2012 at 1:16 AM, Michael Welzl <[email-masked]> wrote:
> Hi all,
> 
> I have read draft-alvestrand-rtcweb-congestion-01.
> 
> 
> High-level comments:
> 
> Today, this has been called a "strawman proposal". I agree with this way of looking at it. There are some quite interesting ideas there; however, a lot seems to appear "out of the blue", leaving the reader puzzled about the rationale behind some design choices. I wonder if these design choices are based on some academic papers out there - could citations help? Anyway, instead of trying to discuss the algorithm "in the air", it would be better to first work with some data: how does the mechanism really work in a real-life system? How does it interact with TCP? How sensitive is this mechanism to the typical issues raised for delay-based controls (the latecomer unfairness problem, behavior with very small queues, ..)? How likely is it for the derived rate of the mechanism to fall below the TFRC-function limit, under what conditions will this happen?
> 
> We are currently working on producing some numbers on performance. It is very helpful to get suggestions on what kind of measurements and scenarios are most interesting.
>  
Given that SCTP is being proposed for data in RTCWeb then the performance against SCTP's default TCP-like algorithm would be relevant. It would seem that since it is loss based it will probably lead to full queues and maximum latency so some alternative probably needs to be sought for SCTP.

I had a question about the use of the Kalman filter being selected as a suitable filter - it's not that clear as to whether the underlying tracked quantities maybe modelled in a linear fashion which is what is expected for the standard Kalman filter.

Piers

> 
> As for the writing style, around the middle of section 3.2 you depart from what I would consider a reasonable amount of equations for an RFC. It might be better to point to a document where the derivation is given.
> 
> 
> 
> Finer-grain comments:
> 
> I got confused by your usage of "frame" - typically, to me, a frame is a packet at the link layer, or a picture in a video. Generally I have the impression that you use the word "frame" to refer to packets, but then towards the end of section 3.2 you talk about "the highest rate at which frames have been captured by the camera".  On a side note, that is anyhow inappropriate, I guess, as this mechanism shouldn't necessarily be restricted to video (could be audio too), right?
> 
> In the draft a frame refers to a video frame. However, if an extension such as http://tools.ietf.org/html/rfc5450 is used frames can be substituted for packets. I agree that the draft shouldn't mention video, as it might as well act on audio frames.
>  
> 
> Same paragraph: "Since our assumption that v(i) should be zero mean WGN is less accurate in some cases" => why?
> 
> Assuming that the jitter has a WGN distribution is a very strong assumption. For instance there are situations where a frame i is queued up behind another frame i-1 and in that situation the jitter will not even be white. 
>  
> 
> Section 3.1: "Since the time ts to send a frame of size L over a path with a capacity C is" => this should at least say "roughly", as it omits a lot of (arguably, perhaps irrelevant) factors.
> 
> Agreed.
> 
> 
> Equation 5: I don't think that m(i) and v(i) have been defined before.  (even though it seems obvious what is meant)
> 
> Probably makes sense to refer to them from the text. E.g., "Breaking out the mean m(i) of w(i), leaving us with the zero mean process v(i), we get"
>  
> 
> Section 3.4: it's confusing to talk about increasing or decreasing "the available bandwidth" - if I got this right, what you do increase or decrease is the *receiver-side estimate* of the available bandwidth.
> 
> Yes, I agree that should be clarified.
>  
> 
> Section 4: par 3, "This algorithm is run every time a receive report arrives..." => so in case of severe congestion, when nothing else arrives, this algorithm waits for 2 * t_max_fb_interval... so can we rely on the mechanism to react to this congestion after roughly an RTO or not? (sounds like not)  Is that bad?  (I guess)
> 
> There is a need for some emergency break mechanism if no feedback gets through.
>  
> 
> I hope that's useful,
> 
> 
> Cheers
> Michael
> 
> _______________________________________________
> Rtp-congestion mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 
> _______________________________________________
> 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/20120329/65b34570/attachment.html
>From [email-masked]  Thu Mar 29 14:42:21 2012
From: [email-masked] (Ashwin Rao)
Date: Thu Mar 29 14:42:04 2012
Subject: [Iccrg] Discussion on Congestion Control for RTP
Message-ID: <[email-masked]>

Hi,

At the iccrg presentations at IETF there were a good number of people
who were interested in working on congestion control for RTP. I am
interested in working on congestion control for RTP I have expressed
my interest to a few people working on RTCWeb at Mozilla. I would like
to know if any one is interested in discussing the problems in this
area. I would like to discuss some problems after the conex meeting
that ends at 19:40 in room 253. We could meet in this room after the
conex presentation and if required move to another room.

Topics that I would like to discuss include
1. Is RTCWeb [ http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01
]  being too conservative with respect to increasing the rate of
sending packets.
2. How to address issues that affect the performance of delay based
congestion control algorithms like TCP Vegas.
3. Lessons learned from LEDBAT.

Regards,
Ashwin

From: [email-masked] (Michael Welzl)
Date: Thu Mar 29 12:55:04 2012
Subject: [Iccrg] Re: [R-C] Comments on draft-alvestrand-rtcweb-congestion-01
In-Reply-To: <CAEdus3L3Ovsnh5hrteh4tw9n-=[email-masked]>
References: <[email-masked]> <CAEdus3L3Ovsnh5hrteh4tw9n-=[email-masked]>
Message-ID: <[email-masked]>

On Mar 29, 2012, at 1:32 PM, Stefan Holmer wrote:

> Hi Michael,
>
> On Wed, Mar 28, 2012 at 1:16 AM, Michael Welzl <[email-masked]>  
> wrote:
> Hi all,
>
> I have read draft-alvestrand-rtcweb-congestion-01.
>
>
> High-level comments:
>
> Today, this has been called a "strawman proposal". I agree with this  
> way of looking at it. There are some quite interesting ideas there;  
> however, a lot seems to appear "out of the blue", leaving the reader  
> puzzled about the rationale behind some design choices. I wonder if  
> these design choices are based on some academic papers out there -  
> could citations help? Anyway, instead of trying to discuss the  
> algorithm "in the air", it would be better to first work with some  
> data: how does the mechanism really work in a real-life system? How  
> does it interact with TCP? How sensitive is this mechanism to the  
> typical issues raised for delay-based controls (the latecomer  
> unfairness problem, behavior with very small queues, ..)? How likely  
> is it for the derived rate of the mechanism to fall below the TFRC- 
> function limit, under what conditions will this happen?
>
> We are currently working on producing some numbers on performance.  
> It is very helpful to get suggestions on what kind of measurements  
> and scenarios are most interesting.

As a starting point, for interaction with TCP, you could perhaps use  
at least parts of the test suite:
http://caia.swin.edu.au/ngen/tcptestsuite/
And for showing that the mechanism works well and isn't prone to the  
typical problems of delay-based mechanism, take a look at the  
literature on delay-based congestion controls - papers on FAST, for  
instance, to check what the authors of these papers have investigated.

Getting such suggestions is what the ICCRG should be for, IMO - fellow  
ICCRGers, please make suggestions!

>
> In the draft a frame refers to a video frame. However, if an  
> extension such as http://tools.ietf.org/html/rfc5450 is used frames  
> can be substituted for packets. I agree that the draft shouldn't  
> mention video, as it might as well act on audio frames.

Oh! That really wasn't clear to me - my bet was that you're really  
talking about packets! Well that should just be clarified.

> Section 4: par 3, "This algorithm is run every time a receive report  
> arrives..." => so in case of severe congestion, when nothing else  
> arrives, this algorithm waits for 2 * t_max_fb_interval... so can we  
> rely on the mechanism to react to this congestion after roughly an  
> RTO or not? (sounds like not)  Is that bad?  (I guess)
>
> There is a need for some emergency break mechanism if no feedback  
> gets through.

I totally agree - what I meant is, it isn't clear to me if that  
emergency break is activated in time or too late. It should be in time  
(i.e. after roughly an RTO).

Cheers,
Michael

From: [email-masked] (Harald Alvestrand)
Date: Thu Mar 29 11:28:06 2012
Subject: [Iccrg] Mailing list for discussing RTP congestion control
Message-ID: <[email-masked]>

Hi,

as promised:
The mailing list that we're informally using for discussing congestion 
control in the RTP context is this:

[email-masked]

You can subscribe by mail to [email-masked], or 
from its web page:
http://www.alvestrand.no/mailman/listinfo/rtp-congestion

Welcome!

                      Harald

From: [email-masked] (Ingemar Johansson S)
Date: Wed Mar 28 12:26:11 2012
Subject: [Iccrg] Presentation material
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi

For the not-so-lucky-to-be-there.. Is the presentation material from ICCRG available somewhere ?

Regards
/Ingemar

=================================
Ingemar Johansson  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com
www.thenodepole.com/ 
=================================
>From [email-masked]  Wed Mar 28 14:16:42 2012
From: [email-masked] (Michael Welzl)
Date: Wed Mar 28 14:16:43 2012
Subject: [Iccrg] Presentation material
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Sure, I received and uploaded all the slides on the morning before the  
meeting, so they're available from the general meeting material page:
https://datatracker.ietf.org/meeting/83/materials.html

Cheers,
Michael

On Mar 28, 2012, at 1:26 PM, Ingemar Johansson S wrote:

> Hi
>
> For the not-so-lucky-to-be-there.. Is the presentation material from  
> ICCRG available somewhere ?
>
> Regards
> /Ingemar
>
> =================================
> Ingemar Johansson  M.Sc.
> Senior Researcher
>
> Ericsson AB
> Wireless Access Networks
> Labratoriegr?nd 11
> 971 28, Lule?, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> [email-masked]
> www.ericsson.com
> www.thenodepole.com/
> =================================
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Wed Mar 28 00:26:35 2012
Subject: [Iccrg] A simple comment about draft-perkins-avtcore-rtp-circuit-breakers
Message-ID: <[email-masked]>

So this is supposed to be for severe situations only, i.e. we want to  
avoid a false positive...

the draft says:

The congestion circuit breaker is therefore: when RTCP RR packets are  
received, estimate the TCP throughput using the above equation and the  
measured R, p (approximated by the loss fraction), and s. Compare this  
with the actual sending rate. If the actual sending rate has been more  
than an order of magnitude greater than the throughput equation  
estimate for two or more RTCP reporting intervals, stop transmitting.
(where "the above equation" is the TCP throughput equation)
but in the presentation today, a statement about reacting when you  
have reached 10 * that value was made. This means that the stream  
would stop sending when it's as aggressive as 10 TCP flows... on a  
host where there can easily be many more flows than that active in  
parallel with the RTP stream, I wouldn't judge that as a "circuit  
breaker" condition. My simple suggestion is to pick a much higher  
value, say 100?

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Wed Mar 28 00:16:55 2012
Subject: [Iccrg] Comments on draft-alvestrand-rtcweb-congestion-01
Message-ID: <[email-masked]>

Hi all,

I have read draft-alvestrand-rtcweb-congestion-01.

High-level comments:

Today, this has been called a "strawman proposal". I agree with this  
way of looking at it. There are some quite interesting ideas there;  
however, a lot seems to appear "out of the blue", leaving the reader  
puzzled about the rationale behind some design choices. I wonder if  
these design choices are based on some academic papers out there -  
could citations help? Anyway, instead of trying to discuss the  
algorithm "in the air", it would be better to first work with some  
data: how does the mechanism really work in a real-life system? How  
does it interact with TCP? How sensitive is this mechanism to the  
typical issues raised for delay-based controls (the latecomer  
unfairness problem, behavior with very small queues, ..)? How likely  
is it for the derived rate of the mechanism to fall below the TFRC- 
function limit, under what conditions will this happen?

As for the writing style, around the middle of section 3.2 you depart  
from what I would consider a reasonable amount of equations for an  
RFC. It might be better to point to a document where the derivation is  
given.

Finer-grain comments:

I got confused by your usage of "frame" - typically, to me, a frame is  
a packet at the link layer, or a picture in a video. Generally I have  
the impression that you use the word "frame" to refer to packets, but  
then towards the end of section 3.2 you talk about "the highest rate  
at which frames have been captured by the camera".  On a side note,  
that is anyhow inappropriate, I guess, as this mechanism shouldn't  
necessarily be restricted to video (could be audio too), right?

Same paragraph: "Since our assumption that v(i) should be zero mean  
WGN is less accurate in some cases" => why?

Section 3.1: "Since the time ts to send a frame of size L over a path  
with a capacity C is" => this should at least say "roughly", as it  
omits a lot of (arguably, perhaps irrelevant) factors.

Equation 5: I don't think that m(i) and v(i) have been defined  
before.  (even though it seems obvious what is meant)

Section 3.4: it's confusing to talk about increasing or decreasing  
"the available bandwidth" - if I got this right, what you do increase  
or decrease is the *receiver-side estimate* of the available bandwidth.

Section 4: par 3, "This algorithm is run every time a receive report  
arrives..." => so in case of severe congestion, when nothing else  
arrives, this algorithm waits for 2 * t_max_fb_interval... so can we  
rely on the mechanism to react to this congestion after roughly an RTO  
or not? (sounds like not)  Is that bad?  (I guess)

I hope that's useful,

Cheers
Michael

From: [email-masked] (Chris-Lei.Liu)
Date: Sat Mar 24 17:30:10 2012
Subject: [Iccrg] Deadline==March 30, FFCN-2012, Liverpool, UK
Message-ID: <[email-masked]>

[Please accept our sincere apologies if you receive multiple copies of this
email]

************************ FFCN-2012 CFP ***********************

The International Symposium on Frontier of Future Communication Networks
(FFCN-2012) to be held in conjunction with The 14th IEEE International
Conference on High Performance computing and communications (IUCC-2012), in
Liverpool, UK.

http://www.lrm.sdu.edu.cn/ffcn2012.html

All accepted papers will be included in the proceedings of the main
conference IUCC 2012, published by IEEE Computer Society Press (Indexed by
EI). At least one author of any accepted paper is requested to register at
the main conference. Once accepted, the paper will be included into the IEEE
conference proceedings published by IEEE Computer Society Press (indexed by
EI). 

=================

-Ad Hoc Networks and Sensor Networks

-Social Networks: Architecture, Theories and Technologies

-Perspective of Cognitive Networks and Development

-Applications and Technologies of Mobile Networks

-Systems, Architecture and Standardizations of Internet of Things

-Performance, Modelling, Analysis and Optimization of Computer Networking  

-Design and Development of IPv6

-Challenges and Issues of Bio-Networks

-Applications, Theories and Utilizations of Biomimicry Networks

Important Dates

==================

Paper submission deadline:        March 30, 2012

Author notification:                        April 30, 2012

Final manuscript due:                     May 12, 2012

Registration due:                             May 12, 2012

Conference date:                            June 25-27, 2012

Submission Instructions

=======================

Authors are invited to submit manuscripts reporting original unpublished
research and recent developments in the topics related to the workshop. The
length of the papers should not exceed 6 pages + 2 pages for overlength
charges (IEEE Computer Society Proceedings Manuscripts style: two columns,
single-spaced), including figures and references, using 10pt fonts, and
number each page. Papers should be submitted electronically in PDF format by
sending it as an e-mail attachment to Lei Liu ([email-masked]).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120325/dfbac125/attachment.html
>From [email-masked]  Sat Mar 24 17:36:02 2012
From: [email-masked] (Chris-Lei.Liu)
Date: Sat Mar 24 17:37:32 2012
Subject: [Iccrg] 
 Firm Deadline=March 30, The Third International Workshop on 
 Intelligent Communication and Social Networks (IntelNet 2012), 
 Liverpool, UK, 25-27 June, 2012
Message-ID: <[email-masked]>

[Please accept our apologies if you receive multiple copies of this email]

************************ IntelNet-2012 CFP ***********************

The Third International Workshop on Intelligent Communication and Social
Networks (IntelNet-2012) in conjunction with The 11th IEEE International
Conference on Ubiquitous Computing and Communications (IUCC-2012) in
Liverpool, UK

 <http://www.lrm.sdu.edu.cn/intelnet2012/1.htm>
http://www.lrm.sdu.edu.cn/intelnet2012/1.htm

Authors are invited to submit manuscripts reporting original unpublished
research and recent developments in the topics related to the workshop. The
length of the papers should not exceed 6 pages + 2 pages for overlength
charges (IEEE Computer Society Proceedings Manuscripts style: two columns,
single-spaced), including figures and references, using 10pt fonts, and
number each page. Papers should be submitted electronically in PDF format by
sending it as an e-mail attachment to Lei Liu ([email-masked]).

All papers will be peer-reviewed and the comments will be provided to the
authors. All accepted papers will be included in the proceedings of the main
conference IUCC 2012, published by IEEE Computer Society Press (Indexed by
EI). At least one author of any accepted paper is requested to register at
the main conference. 

Scope and Topics:

====================

-Applications of Social Networks

-Ad Hoc Networks and Sensor Networks

-Advanced Technologies for Enabling Intelligent Communications

-Autonomy-Oriented Communication Networks

-Biological, Social, and Economic Models for Communication Networks

-Bio-Inspired Network Protocols and Services

-Community Detection in Social Networks  

-Cognitive Networks

-Complex Dynamics of Communication Networks

-Information Acquisition and Establishment of Social Relations

-Intrusion Detection in Social Network Evolution

-Mobile Social Networks

-Network-Aware Social Networks

-Scalability and Complexity of Intelligent Communication Networks

-Self-Organizing, Self-Adaptive and Self-Tuning Communication Networks

-Smart Home Networks

-Stability and Dependability of Intelligent Communication Networks

-Socially-Aware Communication Networks

-Social Networks: Architecture, Theories and Technologies

Important Dates

=====================

Paper submission deadline:        March 30, 2012

Author notification:                        April 30, 2012

Final manuscript due:                     May 12, 2012

Registration due:                             May 12, 2012

Conference date:                            June 25-27, 2012

Submission Instructions

====================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120325/5456d1e1/attachment.html
>From [email-masked]  Tue Mar 27 14:56:58 2012
From: [email-masked] (Bob Briscoe)
Date: Tue Mar 27 15:05:53 2012
Subject: [Iccrg] Refs releated to "(Pre-)congestion notification in mobile
	networks"
Message-ID: <[email-masked]>

Mirja, Sebastien, Isabelle,

This paper describes how congestion signals should be calibrated to 
make them equivalent between radio resources and fixed resources:

Resource Control for Elastic Traffic in CDMA Networks
<http://www.ics.forth.gr/netlab/publications/resource_control_elastic_cdma.html>

It also addresses the radio timescale problem Mirja just mentioned 
(from the mic in the ICCRG meeting). It uses two control loops:
1) a tight power control loop for the radio resource (layer 1),
2) where there is persistent congestion at L1, it drives congestion 
marking that is fed from L2 up to L3 and via TCP feedback to L4 as 
part of the slower e2e control loop.

In addition, the hyperlink below gives a few other related papers 
from the same team, particularly one relating to 802.11 rather than WCDMA.

Bob

>Date: Wed, 14 Mar 2012 09:22:24 +0000
>To: <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: RE: [PCN] Draft "Pre-congestion notification in mobile  networks"
>Cc: <[email-masked]>
>
>Sebastien,
>
>These papers might be relevant. They are about combining congestion 
>marking over an e2e path with radio and fixed resources (2002):
><http://www.ics.forth.gr/netlab/future_wireless.html>
>The Mobicom one is the most relevant for you.
>
>
>Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design  

From: [email-masked] (Michael Welzl)
Date: Wed Mar 21 08:28:58 2012
Subject: [Iccrg] Final agenda for the Paris meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi again,

I'm very sorry - yesterday's agenda didn't turn out to be so "final" 
after all: it accidentally lacked a talk that we had already agreed to 
include. Now I added it - about Laminar, by Matt Mathis. Of course some 
other presentations had to be made a bit shorter now... the good news is 
that the allocation is now very fair: everybody gets 15 minutes in our 
first slot, except for one speaker who only asked for 10  :-)

The now hopefully really final agenda is at:
http://www.ietf.org/proceedings/83/agenda/agenda-83-iccrg.txt

and below.

Cheers,
Michael

****************************************************************************************** 

ICCRG meeting @ IETF 83 (Paris), Tuesday 27 March 2012

Time slot 1, 15:20-17:00

* Congestion Control and Notification over Longer Time Scales and at 
Higher Layers - Dave McDysan (15 min)
   draft-mcdysan-iccrg-usecases-00

* Pre-congestion notification in mobile networks - Sebastien Jobert (10 min)
   draft-jobert-tsvwg-pre-congest-notif-mobile-00

* Caching with TCP - Pasi Sarolahti (15 min)

* On the Fairness of Transport Protocols in a Multi-Path Environment - 
Hakim Adhari (15 min)
   (based on an upcoming ICC 2012 paper)

* End-to-End Transmission Control through Inference about the Network - 
Keith Winstein (15 min)
   (based on: 
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf)

* TCP Reno over Network Coding - Nadia Boukhatem (15 min)
   (based on: 
https://www.usukita.org/papers/5979/TA1_17_Chen_combocoding.pdf)

* Research opportunities related to TCP Laminar - Matt Mathis (15 min)
   draft-mathis-tcpm-tcp-laminar-00

Time slot 2, 17:10-18:10

Topic chair: Harald Alvestrand

* Introduction: The RTCWEB effort, and the traffic we expect to generate 
- Harald (10 min)
   draft-ietf-rtcweb-overview-02
   draft-jesup-rtp-congestion-reqs-00

* Nice behaviour for RTP-based services - Varun Singh, Colin Perkins (10 
min)
   draft-perkins-avtcore-rtp-circuit-breakers-00

* A delay based congestion control candidate - Stefan Holmer (15 min)
   draft-alvestrand-rtcweb-congetstion-01

* Feedback mechanisms that might be useful - Harald Alvestrand (5 min)
   draft-alvestrand-rmcat-remb-00

* A possible WG charter: RMCAT (15 min)
   http://www.ietf.org/iesg/evaluation/rmcat-charter.txt

* Summary, conclusions, next steps (5 min)

From: [email-masked] (Michael Welzl)
Date: Tue Mar 20 12:50:02 2012
Subject: [Iccrg] Final agenda for the Paris meeting
Message-ID: <[email-masked]>

Hi all,

The agenda for the ICCRG meeting @ IETF 83 (Paris), Tuesday 27 March 
2012, is now finalized. You can find it at:
http://www.ietf.org/proceedings/83/agenda/agenda-83-iccrg.txt
and below.

Only slot 1 has changed; note that I had to make some presentations a 
little shorter than the presenters originally requested to fit 
everything in (I think it was well worth doing, as there are a lot of 
interesting topics).

I'd like to use this chance to remind all the presenters that may not be 
used to IETF meetings that things can get more "interactive" than you're 
used to - at IETF-co-located meetings, you can easily get lots of 
questions and even a debate. That's a major part of what makes these 
meetings good, so I don't like having to cut that short. Hence, please 
allow ample time for discussion and expect to not have a very long 
one-way presentation. Thanks!

I'm looking forward to seeing many of you in Paris,

Cheers,
Michael

******************************************************************************************

Time slot 1, 15:20-17:00

* Agenda bashing and update - Michael Welzl (5 min)

* Congestion Control and Notification over Longer Time Scales and at 
Higher Layers - Dave McDysan (20 min)
   draft-mcdysan-iccrg-usecases-00

* Pre-congestion notification in mobile networks - Sebastien Jobert (10 min)
   draft-jobert-tsvwg-pre-congest-notif-mobile-00

* Caching with TCP - Pasi Sarolahti (15 min)

* On the Fairness of Transport Protocols in a Multi-Path Environment - 
Hakim Adhari (15 min)
   (based on an upcoming ICC 2012 paper)

* End-to-End Transmission Control through Inference about the Network - 
Keith Winstein (20 min)
   (based on: 
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf)

* TCP Reno over Network Coding - Nadia Boukhatem (15 min)
   (based on: 
https://www.usukita.org/papers/5979/TA1_17_Chen_combocoding.pdf)

Time slot 2, 17:10-18:10

Topic chair: Harald Alvestrand

* Introduction: The RTCWEB effort, and the traffic we expect to generate 
- Harald (10 min)
   draft-ietf-rtcweb-overview-02
   draft-jesup-rtp-congestion-reqs-00

* Nice behaviour for RTP-based services - Varun Singh, Colin Perkins (10 
min)
   draft-perkins-avtcore-rtp-circuit-breakers-00

* A delay based congestion control candidate - Stefan Holmer (15 min)
   draft-alvestrand-rtcweb-congetstion-01

* Feedback mechanisms that might be useful - Harald Alvestrand (5 min)
   draft-alvestrand-rmcat-remb-00

* A possible WG charter: RMCAT (15 min)
   http://www.ietf.org/iesg/evaluation/rmcat-charter.txt

* Summary, conclusions, next steps (5 min)

From: [email-masked] ([email-masked])
Date: Sat Mar 17 08:43:29 2012
Subject: [Iccrg] Acord Informare produse Dermocosmetice.ro ( 50% reducere! )
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120317/f021eb1f/attachment.html
>From [email-masked]  Mon Mar 19 07:21:06 2012
From: [email-masked] (Thomas Dreibholz)
Date: Mon Mar 19 07:16:56 2012
Subject: [Iccrg] PAMS 2012 -- Call for Participation
Message-ID: <1630090.OajPHTiIzJ@lupo>

[Our apologies if you receive multiple copies of this message.]

CALL FOR PARTICIPATION
We cordially invite you to join us at:

The 2nd International Workshop on
Protocols and Applications with Multi-Homing Support (PAMS 2012)
In conjunction with the 26th IEEE International Conference on
Advanced Information Networkingand Applications (AINA 2012)
Fukuoka, Japan, March 26-29, 2012
http://tdrwww.iem.uni-due.de/pams2012.html

The intent of our proposed workshop is to bring together people from research
and industry, in order to provide a discussion forum for state-of-the-art
topics related to multi-homing on Network, Transport, Session and Application
Layers.

Further details are available at:
http://tdrwww.iem.uni-due.de/pams2012.html

We look forward seeing you in Fukuoka!

From: [email-masked] (Chris-Lei.Liu)
Date: Tue Mar 13 06:35:05 2012
Subject: [Iccrg]  Submission deadline is approaching, IntelNet2012, Liverpool, UK
Message-ID: <[email-masked]>

[Please accept our apologies if you receive multiple copies of this email]

************************ IntelNet-2012 CFP ***********************

The Third International Workshop on Intelligent Communication and Social
Networks (IntelNet-2012) in conjunction with The 11th IEEE International
Conference on Ubiquitous Computing and Communications (IUCC-2012) in
Liverpool, UK

 <http://www.lrm.sdu.edu.cn/intelnet2012/1.htm>
http://www.lrm.sdu.edu.cn/intelnet2012/1.htm

Introduction

====================

Modern communication networks have been becoming more and more large-scaled
and complicated due to rapid development and interconnection among
heterogeneous communication networks. Therefore, the management and
maintenance of modern communication networks have posed many grand
challenges to both industrial and academic communication communities.
Especially in very recent years, interpersonal communication has been
re-emerging as an important research issue, as people have turned to social
networking as a means of communication. Mass media has gradually replaced
interpersonal communications a socializing force. Therefore, it is very
necessary to find new levels of autonomy and intelligence in designing,
deploying, managing, and maintaining communication networks. Meanwhile,
analysis of communities, personalization for social activities, and social
network modeling, construction of scalable, customizable social network
infrastructure have brought researchers new challenges. 

The purpose of the 2012 International Workshop on Intelligent Communication
and Social Networks (IntelNet 2012) is to bring together scientists,
researchers, professionals, and practitioners from both industry and
academia to exchange ideas, discuss solutions, share experiences, and report
state-of-the-art research results on various aspects of intelligence
communication and social networks. 

Scope and Topics:

====================

-Applications of Social Networks

-Ad Hoc Networks and Sensor Networks

-Advanced Technologies for Enabling Intelligent Communications

-Autonomy-Oriented Communication Networks

-Biological, Social, and Economic Models for Communication Networks

-Bio-Inspired Network Protocols and Services

-Community Detection in Social Networks  

-Cognitive Networks

-Complex Dynamics of Communication Networks

-Information Acquisition and Establishment of Social Relations

-Intrusion Detection in Social Network Evolution

-Mobile Social Networks

-Network-Aware Social Networks

-Scalability and Complexity of Intelligent Communication Networks

-Self-Organizing, Self-Adaptive and Self-Tuning Communication Networks

-Smart Home Networks

-Stability and Dependability of Intelligent Communication Networks

-Socially-Aware Communication Networks

-Social Networks: Architecture, Theories and Technologies

Important Dates

=====================

Paper submission deadline:        March 30, 2012

Author notification:                        April 30, 2012

Final manuscript due:                     May 08, 2012

Registration due:                             May 08, 2012

Conference date:                            June 25-27, 2012

Submission Instructions

====================

Authors are invited to submit manuscripts reporting original unpublished
research and recent developments in the topics related to the workshop. The
length of the papers should not exceed 6 pages + 2 pages for overlength
charges (IEEE Computer Society Proceedings Manuscripts style: two columns,
single-spaced), including figures and references, using 10pt fonts, and
number each page. Papers should be submitted electronically in PDF format by
sending it as an e-mail attachment to Lei Liu ([email-masked]).

All papers will be peer-reviewed and the comments will be provided to the
authors. All accepted papers will be included in the proceedings of the main
conference IUCC 2012, published by IEEE Computer Society Press (Indexed by
EI). At least one author of any accepted paper is requested to register at
the main conference. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120313/b6a0f295/attachment.html
>From [email-masked]  Wed Mar 14 11:46:25 2012
From: [email-masked] (Pasi Sarolahti)
Date: Wed Mar 14 11:47:42 2012
Subject: [Iccrg] Transport layer caching
In-Reply-To: <CAK6E8=[email-masked]>
References: <9[email-masked]>
	<[email-masked]>
	<CAK6E8=[email-masked]>
Message-ID: <[email-masked]>

On Mar 12, 2012, at 7:23 PM, Yuchung Cheng wrote:

>> In brief, the idea is to label TCP segments with cachable data using a "Content Label" TCP option. These segments could then be cached and re-used across connections by segment caches in the network, to reduce the load at the original server.
>> 
> This is an interesting proposal. Any data on the savings of this idea?
> e.g. popular CDN servers etc.

Currently we don't have data on popular CDN servers or such, simply because we do not have access to them (this needs sender-side modifications to TCP). We have implemented this on Linux, and have some simulation results with ns-3 using the Linux stack in the simulation cradle. We also did some experiments between a few hosts located in different continents (Asia, North/South America, Europe) running a HTTP server, to verify that it works also over the real Internet. I plan to show (briefly) some of those results in the meeting.

- Pasi

From: [email-masked] (Yuchung Cheng)
Date: Mon Mar 12 17:20:16 2012
Subject: [Iccrg] Transport layer caching
In-Reply-To: <[email-masked]>
References: <9[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

On Sun, Mar 11, 2012 at 1:58 PM, Pasi Sarolahti <[email-masked]> wrote:
> Hi,
>
> On Mar 10, 2012, at 11:41 AM, Nestor Michael C. Tiglao wrote:
>
>> I am interested about the Caching with TCP talk. ?I'm doing work on transport layer caching applied to WSNs. ?The attached paper could be relevant
>
> The Internet-draft related to this talk is available at
> http://tools.ietf.org/html/draft-sarolahti-irtf-catcp-00
>
> In brief, the idea is to label TCP segments with cachable data using a "Content Label" TCP option. These segments could then be cached and re-used across connections by segment caches in the network, to reduce the load at the original server.
>
This is an interesting proposal. Any data on the savings of this idea?
e.g. popular CDN servers etc.

From: [email-masked] (sebastien.jobert)
Date: Fri Mar  9 00:27:36 2012
Subject: [Iccrg] Draft "Pre-congestion notification in mobile networks"
Message-ID: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0352004D@ftrdmel1>

Hi all,

We have uploaded an Internet-Draft called "Pre-congestion notification in mobile networks" - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf

Abstract

   Mobile networks may be divided into two main segments: the radio

   segment, and the wireline segment. This document highlights that the

   algorithms leading to pre-congestion notification (e.g. ECN marking)

   are usually significantly different for these two segments, and not

   defined or documented in general over the radio segment. It also

   explains that using ECN bits leads to having a unique signal for

   notifying a pre-congestion related to two separate segments with

   very different notification algorithms. Some consequences are

   questioned, as well as the potential benefits of being able to

   identify where the congestion comes from. This document finally

   discusses the possibility to take into account the radio conditions

   of the terminals when counting the volume of congestion over the

   radio segment.

It has been posted in TSVWG, but the chairs indicated some possible interest from ICCRG.

We are interested by review and comments.

Thanks.

Best Regards,

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120309/13b45355/attachment.html
>From [email-masked]  Sat Mar 10 15:37:54 2012
From: [email-masked] (Chris-Lei.Liu)
Date: Sat Mar 10 15:37:51 2012
Subject: [Iccrg] CFP::The International Symposium on Frontier of Future
 Communication Networks, Liverpool, UK, deadline=30 March 2012
Message-ID: <[email-masked]>

[Please accept our sincere apologies if you receive multiple copies of this
email]

************************ FFCN-2012 CFP ***********************

The International Symposium on Frontier of Future Communication Networks
(FFCN-2012) to be held in conjunction with The 14th IEEE International
Conference on High Performance computing and communications (HPCC-2012), in
Liverpool, UK.

http://www.lrm.sdu.edu.cn/ffcn2012.html

Introduction

================

The demand of next generation networks for communications has focused on the
trend in technology and the efficiency. Driven by the fancy technologies and
the applications, the provisioning of large-scaled and complicated
communication networks is becoming an important research issue. Especially
over the last few years, there has been an explosion of wireless subscribers
and booming growth in the Internet both in terms of users and usage.  The
trend has led to a new direction, and meanwhile brought many grand
challenges to both industrial and academic communication communities. To
overcome these challenges, it is necessary to seek new levels of research
work on architecture, green networking, performance, and intelligence of
future communication networks. All papers will be peer-reviewed and the
comments will be provided to the authors. All accepted papers will be
included in the proceedings of the main conference IUCC 2012, published by
IEEE Computer Society Press (Indexed by EI). At least one author of any
accepted paper is requested to register at the main conference. Once
accepted, the paper will be included into the IEEE conference proceedings
published by IEEE Computer Society Press (indexed by EI). 

 

The purpose the 2012 International Symposium on Frontier of Future
Communication Networks is to bring together scientists, researchers,
professionals, and practitioners from both industry and academia to share
the opinions, seek the solutions, and report state-of-art research results. 

Scope and Topics:

=================

-Ad Hoc Networks and Sensor Networks

-Social Networks: Architecture, Theories and Technologies

-Perspective of Cognitive Networks and Development

-Applications and Technologies of Mobile Networks

-Systems, Architecture and Standardizations of Internet of Things

-Performance, Modelling, Analysis and Optimization of Computer Networking  

-Design and Development of IPv6

-Challenges and Issues of Bio-Networks

-Applications, Theories and Utilizations of Biomimicry Networks

Important Dates

==================

Paper submission deadline:        March 30, 2012

Author notification:                        April 30, 2012

Final manuscript due:                     May 08, 2012

Registration due:                             May 08, 2012

Conference date:                            June 25-27, 2012

Submission Instructions

=======================

Authors are invited to submit manuscripts reporting original unpublished
research and recent developments in the topics related to the workshop. The
length of the papers should not exceed 6 pages + 2 pages for overlength
charges (IEEE Computer Society Proceedings Manuscripts style: two columns,
single-spaced), including figures and references, using 10pt fonts, and
number each page. Papers should be submitted electronically in PDF format by
sending it as an e-mail attachment to Lei Liu ([email-masked]).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120310/65d28a43/attachment.html
>From [email-masked]  Sat Mar 10 09:41:34 2012
From: [email-masked] (Nestor Michael C. Tiglao)
Date: Sun Mar 11 12:40:49 2012
Subject: [Iccrg] Transport layer caching
Message-ID: <[email-masked]>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: transport_layer_caching.pdf
Type: application/pdf
Size: 712255 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120310/f7d75fb4/transport_layer_caching-0001.pdf
>From [email-masked]  Sun Mar 11 20:58:13 2012
From: [email-masked] (Pasi Sarolahti)
Date: Sun Mar 11 20:54:46 2012
Subject: [Iccrg] Transport layer caching
In-Reply-To: <9[email-masked]>
References: <9[email-masked]>
Message-ID: <[email-masked]>

Hi,

On Mar 10, 2012, at 11:41 AM, Nestor Michael C. Tiglao wrote:

> I am interested about the Caching with TCP talk.  I'm doing work on transport layer caching applied to WSNs.  The attached paper could be relevant

The Internet-draft related to this talk is available at
http://tools.ietf.org/html/draft-sarolahti-irtf-catcp-00

In brief, the idea is to label TCP segments with cachable data using a "Content Label" TCP option. These segments could then be cached and re-used across connections by segment caches in the network, to reduce the load at the original server.

Thanks for the paper, I will read it soon.

- Pasi

From: [email-masked] (Eggert, Lars)
Date: Mon Mar  5 08:09:13 2012
Subject: [Iccrg] Fwd: [R-C] New Version Notification for  draft-jesup-rtp-congestion-reqs-00.txt
References: <[email-masked]>
Message-ID: <[email-masked]>

FYI. I believe this draft is of interest.

Begin forwarded message:

> From: Harald Alvestrand <[email-masked]>
> Subject: [R-C] Fwd: New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt
> Date: March 4, 2012 15:20:20 GMT+01:00
> To: "[email-masked]" <[email-masked]>
> 
> And ... it's out!
> Thanks for the quick feedback during the weekend!
> 
>               Harald
> 
> -------- Original Message --------
> Subject: 	New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt
> Date: 	Sun, 04 Mar 2012 06:19:29 -0800
> From: 	[email-masked]
> To: 	[email-masked]
> CC: 	[email-masked]
> 
> 
> 
> A new version of I-D, draft-jesup-rtp-congestion-reqs-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
> 
> Filename:	 draft-jesup-rtp-congestion-reqs
> Revision:	 00
> Title:		 Congestion Control Requirements For Real Time Media
> Creation date:	 2012-03-04
> WG ID:		 Individual Submission
> Number of pages: 7
> 
> Abstract:
>   Congestion control is needed for all data transported across the
>   Internet, in order to promote fair usage and prevent congestion
>   collapse.  The requirements for interactive, point-to-point real time
>   multimedia, which needs by low-delay, semi-reliable data delivery,
>   are different from the requirements for bulk transfer like FTP or
>   bursty transfers like Web pages, and the TCP algorithms are not
>   suitable for this traffic.
> 
>   This document attempts to describe a set of requirements that can be
>   used to evaluate other congestion control mechanisms in order to
>   figure out their fitness for this purpose.
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> Rtp-congestion mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion

-------------- 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/20120305/233a4ec2/smime.bin
>From [email-masked]  Wed Mar  7 15:10:23 2012
From: [email-masked] (Michael Welzl)
Date: Wed Mar  7 15:07:43 2012
Subject: [Iccrg] Preliminary agenda for ICCRG meeting @ IETF 83
Message-ID: <[email-masked]>

Ladies and gentlemen,

Let me present to you the preliminary agenda for the ICCRG meeting at 
the upcoming Paris IETF, which is scheduled on Tuesday afternoon, in the 
15:20-17:00 and 17:10-18:10 time slots. The second time slot is 
dedicated to congestion control for RTP-carried real-time media; this is 
an effort that comes out of rtcweb, with its own mailing list, see: 
http://www.alvestrand.no/mailman/listinfo/rtp-congestion
The group is considering formation of a new WG, and that's why there is 
an item called "a possible WG charter" in the agenda - however, note 
that this meeting is not meant as a surrogate for a BoF (which is 
clearly not what a RG could or should "host"), so this will be just 
informational, not a time slot for wordsmithing. Content-wise, 
congestion control for RTP seems to be clearly in scope of ICCRG, and so 
I expect this to be an interesting session for all of us.

Time slot 1, 15:20-17:00

* Agenda bashing and update - Michael Welzl (5 min)

* Congestion Control and Notification over Longer Time Scales and at 
Higher Layers - Dave McDysan (20 min)
   draft-mcdysan-iccrg-usecases-00

* On the Fairness of Transport Protocols in a Multi-Path Environment - 
Hakim Adhari (15 min)
   (based on an upcoming ICC 2012 paper)

* Caching with TCP - Pasi Sarolahti (15 min)

* End-to-End Transmission Control through Inference about the Network - 
Keith Winstein (30 min)
   (based on: 
http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf)

Time slot 2, 17:10-18:10

Topic chair: Harald Alvestrand

     * Introduction: The RTCWEB effort, and the traffic we expect to 
generate - Harald (10 min)
           o Doc: draft-ietf-rtcweb-overview-02
           o Doc: draft-jesup-rtp-congestion-reqs-00
     * Nice behaviour for RTP-based services - Varun Singh, Colin 
Perkins (10 min)
           o Doc: draft-perkins-avtcore-rtp-circuit-breakers-00
     * A delay based congestion control candidate - Stefan Holmer (15 min)
           o Doc: draft-alvestrand-rtcweb-congetstion-01
     * Feedback mechanisms that might be useful - Harald Alvestrand (5 min)
           o Doc: draft-alvestrand-rmcat-remb-00
     * A possible WG charter: RMCAT (15 min)
           o Doc: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt
     * Summary, conclusions, next steps (5 min)

The times in slot 1 are based on what the presenters requested, but I'd 
think that not everyone has planned for the normal (long) duration of 
discussions at IETF meetings, and so it's nice to have some headroom. 
This being said, I think we can still squeeze a presentation in there if 
need be.

Cheers,
Michael