Subject: [R-C] [Iccrg] Re: Timely reaction time (Re: Comments on draft-alvestrand-rtcweb-congestion-01)
From: [email-masked] (Michael Welzl)
Date: Mon Apr 2 16:44:57 2012

ok - but anyway now i think that this is generally not the best way to  
do it ... i'm curious to hear comments about my other mail re sctp...

Sent from my iPod

On Apr 2, 2012, at 14:04, Stefan Holmer <[email-masked]> wrote:

> I think what you are requesting should be possible with the  
> requirement that the REMB feedback messages should be sent  
> periodically. If none is received within some threshold the sender  
> have to start backing off. REMB are typically sent periodically  
> anyway to be able to probe the channel.
>
> /Stefan
>
> On Mon, Apr 2, 2012 at 7:44 AM, Michael Welzl <[email-masked]>  
> wrote:
> Argh, yes, I guess this one letter was the cause of a  
> misunderstanding... Thanks!
>
> Sent from my iPod
>
> On Apr 1, 2012, at 23:56, Lachlan Andrew <[email-masked]>  
> wrote:
>
> Greetings Michael,
>
> Are you saying you need an emergency "brake" (i.e., slowing down)
> rather than emergency "break" (i.e., termination, with or without a
> restart later)?
>
> Cheers,
> Lachlan
>
>
> On 30 March 2012 21:17, Michael Welzl <[email-masked]> wrote:
>
> 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
>
>
>
> -- 
> Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
> Swinburne University of Technology, Melbourne, Australia
> <http://caia.swin.edu.au/cv/landrew>
> Ph +61 3 9214 4837
> _______________________________________________
> 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/20120402/6109c913/attachment.html
>From [email-masked]  Tue Apr 10 10:40:59 2012
From: [email-masked] (Eggert, Lars)
Date: Tue Apr 10 10:39:41 2012
Subject: [Iccrg] Call for Nominations: Applied Networking Research Prize 2012
Message-ID: <[email-masked]>

                       CALL FOR NOMINATIONS:
         
            APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2012
               
                       http://irtf.org/anrp

***    Submit nominations for the 2012 award period of the        ***
***   Applied Networking Research Prize until May 13, 2012!       ***

The Applied Networking Research Prize (ANRP) is awarded for recent
results in applied networking research that are relevant for
transitioning into shipping Internet products and related
standardization efforts. Researchers with relevant, recently
published results are encouraged to apply for this prize, which will
offer them the opportunity to present and discuss their work with
the engineers, network operators, policy makers and scientists that
participate in the Internet Engineering Task Force (IETF) and its
research arm, the Internet Research Task Force (IRTF).

The goal of the Applied Networking Research Prize is to recognize
the best new ideas in networking, and bring them to the IETF and
IRTF especially in cases where they would not otherwise see much
exposure or discussion.

The Applied Networking Research Prize (ANRP) consists of:

  * cash prize of $500 (USD)
  
  * travel grant to attend a week-long IETF meeting
    (airfare, hotel, registration, stipend)
    
  * invited talk at the IRTF Open Meeting
  
  * recognition at the IETF plenary
  
  * invitation to related social activities
  
  * potential for additional travel grants to future IETF
    meetings, based on community feedback

HOW TO NOMINATE

Only a single person can be nominated for the award. The basis of
the nomination is a peer-reviewed, recently-published, original
journal, conference or workshop paper they authored. The nominee
must be one of the main authors of the nominated paper. Both self
nominations (nominating one?s own paper) and third-party nominations
(nominating someone else?s paper) are encouraged.

The nominated paper should provide a scientific foundation for
possible future IETF engineering work or IRTF research and
experimentation, analyze the behavior of Internet protocols in
operational deployments or realistic testbeds, make an important
contribution to the understanding of Internet scalability,
performance, reliability, security or capability, or otherwise be of
relevance to ongoing or future IETF or IRTF activities.

Applicants must briefly describe how the nominated paper relates to
these goals, and are encouraged to describe how a presentation of
these research results would foster their transition into new IETF
engineering or IRTF experimentation, or otherwise seed new
activities that will have an impact on the real-world Internet.

The goal of the Applied Networking Research Prize (ANRP) is to
foster the transitioning of research results into real-world
benefits for the Internet. Therefore, applicants must indicate that
they (or the nominee, in case of third-party nominations) are
available to attend at least one of the year?s IETF meetings in
person and in its entirety.

Nominations must include:

  * the name and email address of the nominee

  * a bibliographic reference to the published nominated paper

  * a PDF copy of the nominated paper

  * a statement that describes how the nominated paper fulfills the
    goals of the award

  * a statement about which of the year?s IETF meetings the nominee
    would be available to attend in person and in its entirety

  * a brief biography or CV of the nominee

  * optionally, any other supporting information (link to nominee?s
    web site, etc.)

Nominations are submitted via the submission site at
http://irtf.org/anrp/2012/. In exceptional cases, nominations may
also be submitted by email to [email-masked].

SELECTION PROCESS

A small selection committee comprised of individuals knowledgeable
about the IRTF, IETF and the broader networking research community
will evaluate the submissions against these selection criteria.

IMPORTANT DATES

Applications close:  May 13, 2012 (hard)
Notifications:       June 1, 2012

SPONSORS

The Applied Networking Research Prize (ANRP) is supported by the
Internet Society (ISOC), as part of its Internet Research Award
Programme, in coordination with the Internet Research Task Force
(IRTF).

HELP PUBLICIZE THE ANRP

If you would like to help publicize the ANRP within your
organization, you are welcome to print and use the flyer at
http://irtf.org/anrp-2012-flyer.pdf

-------------- 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/20120410/7da07153/smime.bin

From: [email-masked] (Michael Welzl)
Date: Mon Apr  2 06:44:25 2012
Subject: [Iccrg] Re: Timely reaction time (Re: [R-C] Comments on  draft-alvestrand-rtcweb-congestion-01)
In-Reply-To: <CAPpWWaJrZ9p76Zo4=[email-masked]>
References: <[email-masked]> <CAEdus3L3Ovsnh5hrteh4tw9n-=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAPpWWaJrZ9p76Zo4=[email-masked]>
Message-ID: <[email-masked]>

Argh, yes, I guess this one letter was the cause of a  
misunderstanding... Thanks!

Sent from my iPod

On Apr 1, 2012, at 23:56, Lachlan Andrew <[email-masked]>  
wrote:

> Greetings Michael,
>
> Are you saying you need an emergency "brake" (i.e., slowing down)
> rather than emergency "break" (i.e., termination, with or without a
> restart later)?
>
> Cheers,
> Lachlan
>
> On 30 March 2012 21:17, Michael Welzl <[email-masked]> wrote:
>>
>> 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
>
>
>
> -- 
> Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
> Swinburne University of Technology, Melbourne, Australia
> <http://caia.swin.edu.au/cv/landrew>
> Ph +61 3 9214 4837

From: [email-masked] (Lachlan Andrew)
Date: Sun Apr  1 22:55:58 2012
Subject: [Iccrg] Re: 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]> <[email-masked]> <[email-masked]>
Message-ID: <CAPpWWaJrZ9p76Zo4=[email-masked]>

Greetings Michael,

Are you saying you need an emergency "brake" (i.e., slowing down)
rather than emergency "break" (i.e., termination, with or without a
restart later)?

Cheers,
Lachlan

On 30 March 2012 21:17, Michael Welzl <[email-masked]> wrote:
>
> 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

-- 
Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Michael Welzl)
Date: Sun Apr  1 10:26:57 2012
Subject: [Iccrg] ICCRG meeting minutes
Message-ID: <[email-masked]>

Hi all,

I have uploaded the minutes to:  http://www.ietf.org/proceedings/83/minutes/minutes-83-iccrg.txt

Thanks a lot to Gorry Fairhurst for taking them!!

Please send any comments / corrections to the ICCRG list. Thanks!

Cheers,
Michael