Subject: [Rmt] congestion control in FLUTE

From: Magnus Westerlund <[email-masked]>
Date: Fri, 01 Dec 2006 14:26:55 +0100

Hi,

As FLUTE is an application of the RMT building blocs I think it needs to 
specify how the hell you actually apply some congestion control on the 
sessions. In section 4 there is discussion about four scenarios of how 
this may be done. I think it will be necessary to flesh out how one 
actually perform A and C using the available tools. That means 
specifying how you actually can apply WEBRC and TFMCC to flute and what 
restrictions that do apply. It might not be necessary to define both, 
however we do need something that works well in most deployments where 
FLUTE is used.

It would also be really good to see someone write up the glue that is 
need to enable implementation of WEBRC. There seem to be need for 
clarification on how to handle the WEBRC channels and in addition how 
one signal this to the receivers using SDP.

I want to get this going as I don't think we will be able to proceed to 
standards track with flute unless we have a solid congestion control story.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: <[email-masked]>
Date: Wed, 6 Dec 2006 16:38:08 +0200

FLUTE's approach is inherited from ALC - i.e. this needs doing for ALC
and then FLUTE inherits the solution. I would have thought it absolutely
should not be further described in FLUTE (possibly not in ALC either)
according to the RMT building block approach. Is that about right?

Cheers, Rod.

>-----Original Message-----
>From: ext Magnus Westerlund [mailto:[email-masked]] 
>Sent: 01 December, 2006 15:27
>To: [email-masked]
>Subject: [Rmt] congestion control in FLUTE
>
>Hi,
>
>As FLUTE is an application of the RMT building blocs I think 
>it needs to specify how the hell you actually apply some 
>congestion control on the sessions. In section 4 there is 
>discussion about four scenarios of how this may be done. I 
>think it will be necessary to flesh out how one actually 
>perform A and C using the available tools. That means 
>specifying how you actually can apply WEBRC and TFMCC to flute 
>and what restrictions that do apply. It might not be necessary 
>to define both, however we do need something that works well 
>in most deployments where FLUTE is used.
>
>It would also be really good to see someone write up the glue 
>that is need to enable implementation of WEBRC. There seem to 
>be need for clarification on how to handle the WEBRC channels 
>and in addition how one signal this to the receivers using SDP.
>
>I want to get this going as I don't think we will be able to 
>proceed to standards track with flute unless we have a solid 
>congestion control story.
>
>Cheers
>
>Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Dec 2006 15:46:46 +0100

> according to the RMT building block approach. Is that about right?

Hi Rod,

I don't agree. Flute is in my eyes an protocol instantiation and is thus 
the right place to describe these things.

cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Wed, 6 Dec 2006 16:57:14 +0200

In principle I don't have any objection. In practice, any CC has to be
for a purpose so I had thought that within the CC would be the right
place - likewise (although we don't have a mountain of CC proposals), it
didn't seem sensible to put specific CC block into FLUTE as future ones
can not be anticipated (we took out some of the specific FEC stuff
already).

If consensus is to do this in a PI, then shouldn't be in ALC and FLUTE
merely inherits? (Same amount of effort, but then the spec is correctly
available to any other ALC-PI based protocols).

(I'm not pedantic about any of this, though recent history hasn't shown
much frantic activity in the FLUTE camp to address another round of
security analysis and if a better place for a CC-binding is ALC that, at
least, wouldn't stretch the FLUTE update further).

Anyone else got a view?

Cheers, Rod.

>Sent: 06 December, 2006 16:47
>To: Walsh Rod (Nokia-NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: [Rmt] congestion control in FLUTE
>
>> and then FLUTE inherits the solution. I would have thought it 
>> absolutely should not be further described in FLUTE (possibly not in 
>> ALC either) according to the RMT building block approach. Is 
>that about right?
>> 
>
>Hi Rod,
>
>I don't agree. Flute is in my eyes an protocol instantiation 
>and is thus the right place to describe these things.
>
>cheers
>
>Magnus Westerlund
>