Subject: RE: [PCN] Alternatives to Preemption

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Wed, 20 Dec 2006 08:06:13 -0600

Folks,

Since preemption is sometimes viewed as an "inflammatory" topic, it does seem better to take the approach of separating the detection and notification of congestion from the collection of possible actions that can be taken to rectify it.

Stuart Goldman
Alcatel-Lucent 
[email-masked]
602 493 8438

-----Original Message-----
From: Attila Báder (IJ/ETH) [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 5:11 AM
To: Magnus Westerlund (KI/EAB); James M. Polk
Cc: [email-masked]
Subject: RE: [PCN] Alternatives to Preemption

Hi All,

I also support the idea to think of and supporting different applications. The problem of congestion notification and the action to decrease the load can be well separated. 

In the notificaion part it is important to indicate the congestion level. It can be application specific how to decrease the load to the appropriate level.

Best regards, Attila

>-----Original Message-----
>From: Magnus Westerlund [mailto:[email-masked]] 
>Sent: Tuesday, December 19, 2006 10:04 AM
>To: James M. Polk
>Cc: [email-masked]
>Subject: Re: [PCN] Alternatives to Preemption
>
>James M. Polk skrev:
>> At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote:
>>> Hi,
>>>
>>> So far the discussion has been quite focused on preemption when the 
>>> resources gets overtaxed. Aren't there some cases when the 
>>> alternative to preemption would be to indicate to the flows 
>that they 
>>> may only use less resources? This could happen by having the QoS 
>>> mechanism engage in re-negotiation.
>>>
>>> For example in cases when large parts of the traffic is voice, then 
>>> one could change the encoding or change codec mode to 
>reduce the rate.
>> 
>> Magnus
>> 
>> What would a feedback (back to a calling party phone, for example) 
>> look like in this context?
>> 
>
>As mentioned before I can see several possible ways. One that 
>I like is to enable the PCN marking to reach the receiving 
>entity that uses some back-channel, e.g. RTCP, to move the 
>marking back to the sender. I do not assume that there is 
>bi-directional media traffic nor that it will have the same 
>path. Another case would be for the ingress router to use the 
>QoS signalling protocol to re-negotiate the parameters. 
>However I think the above type would be simpler to get working 
>correctly. It also seem to provide some possibility to allow 
>for flows to utilize over capacity when available.
>
>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]
>----------------------------------------------------------------------
>
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pcn
>

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

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