Subject: [PCN] Alternatives to Preemption

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Dec 2006 15:48:02 +0100

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. Isn't 
most operator more in favor of reduced quality, rather than dropped calls?

To be clear, this is a subject I would like to have some opinion from 
the group on to see if it is important to consider in the development. 
However I don't see how it would be in the first phase of a PCN WG other 
than as a constraint.

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Dec 2006 11:59:41 -0600

At 03:48 PM 12/18/2006 +0100, Magnus Westerlund wrote:
>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.
>
>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?

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 18 Dec 2006 13:54:47 -0500

Yes, changing of codec to a lower rate on the detection of onset of
congestion is an option that needs to be supported. However, the
changing of codecs only is possible if both endpoints have this
capability so not all flows will respond. Yes, I'm interested in working
on this problem in later phase of the PCN work.

Regards, Joe
Email: [email-masked]
-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 9:48 AM
To: [email-masked]
Subject: [PCN] Alternatives to Preemption

Hi,

most operator more in favor of reduced quality, rather than dropped
calls?

than as a constraint.

Cheers

Magnus Westerlund

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 18 Dec 2006 14:15:06 -0500

James one possible way that this could work is that during session
setup, two codecs are negotiated in the SDP offer message, the first
being high quality higher rate codec and the second a lower rate codec.
When onset of congestion is detected, the PCN marking triggers the
endpoints to switch to lower rate codec. The receiver of the RTP steam
(phone) needs to signal to the sender possible using RTCP the codec
change request. 

Regards, Joe

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 1:00 PM
To: Magnus Westerlund; [email-masked]
Subject: Re: [PCN] Alternatives to Preemption

>resources gets overtaxed. Aren't there some cases when the alternative
to 

Magnus

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Dec 2006 15:07:34 -0600

Jozef

This is an interesting way of doing a solution, however, I do not see what 
type of message is sent by the core edge to the actual phone to tell it to 
do anything.  SIP messaging (with SDP inside) can and probably does take an 
entirely different path to set up the call than the RTP media packets take, 
therefore - something needs to be on the RTP path giving feedback.  This 
could be RTCP, but is that sent by the core edge router? I don't believe so 
(unless this node is also an SBC). Therefore, what does send this message 
and what could it be in the form of?

I'm wondering if Magnus is assuming the ingress and egress of bidirectional 
RTP pcakets traverse the same core edge router?

I'm not looking for a solution as much as I'm looking for what people might 
be thinking a solution could look like.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 19 Dec 2006 08:47:56 +0100

James,

in general I think there are two possibilities:

You mentioned an edge element which somehow is able to inform 
the SIP proxy (or RSVP edge router) controlling a session 
that it received congestion/preemption marked packets related 
to this session.

The other option is to forward PCN or DSCP marked media packets 
to the end system and inform it that way. RTCP could be adapted 
to report congestion marked packets. But also the receivers 
SIP stack could be adapted to interpret these packets and 
then start to re-negotiate codecs.

The general aim of codec adaptation in the case of congestion 
seems useful to me and I think PCN should work on it once the 
basic PCN mechanisms are specified.

Regards,

Rudiger

|-----Original Message-----
|From: James M. Polk [mailto:[email-masked]]
|Sent: Monday, December 18, 2006 10:08 PM
|To: Jozef Babiarz; Magnus Westerlund; [email-masked]
|Subject: RE: [PCN] Alternatives to Preemption
|
|
|Jozef
|
|This is an interesting way of doing a solution, however, I do 
|not see what 
|type of message is sent by the core edge to the actual phone 
|to tell it to 
|do anything.  SIP messaging (with SDP inside) can and probably 
|does take an 
|entirely different path to set up the call than the RTP media 
|packets take, 
|therefore - something needs to be on the RTP path giving 
|feedback.  This 
|could be RTCP, but is that sent by the core edge router? I 
|don't believe so 
|(unless this node is also an SBC). Therefore, what does send 
|this message 
|and what could it be in the form of?
|
|I'm wondering if Magnus is assuming the ingress and egress of 
|bidirectional 
|RTP pcakets traverse the same core edge router?
|
|I'm not looking for a solution as much as I'm looking for what 
|people might 
|be thinking a solution could look like.
|
|At 02:15 PM 12/18/2006 -0500, Jozef Babiarz wrote:
|>James one possible way that this could work is that during session
|>setup, two codecs are negotiated in the SDP offer message, the first
|>being high quality higher rate codec and the second a lower 
|rate codec.
|>When onset of congestion is detected, the PCN marking triggers the
|>endpoints to switch to lower rate codec. The receiver of the RTP steam
|>(phone) needs to signal to the sender possible using RTCP the codec
|>change request.
|>
|>Regards, Joe
|>Email: [email-masked]
|>
|>-----Original Message-----
|>From: James M. Polk [mailto:[email-masked]]
|>Sent: Monday, December 18, 2006 1:00 PM
|>To: Magnus Westerlund; [email-masked]
|>Subject: Re: [PCN] Alternatives to Preemption
|>
|>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?
|>
|> >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
|

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Dec 2006 09:29:24 +0100

Hi Magnus

I am also interested in working on this problem and yes it should be
considered as a constraint!

Best Regards,
Georgios 

> From: Jozef Babiarz [mailto:[email-masked]] 
> Sent: maandag 18 december 2006 19:55
> Subject: RE: [PCN] Alternatives to Preemption
> 
> Yes, changing of codec to a lower rate on the detection of 
> onset of congestion is an option that needs to be supported. 
> However, the changing of codecs only is possible if both 
> endpoints have this capability so not all flows will respond. 
> Yes, I'm interested in working on this problem in later phase 
> of the PCN work.
> 
> Regards, Joe
> 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. Isn't
> 
> To be clear, this is a subject I would like to have some 
> opinion from the group on to see if it is important to 
> consider in the development.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Dec 2006 10:04:29 +0100

James M. Polk skrev:
>> 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
> 

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

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Wed, 20 Dec 2006 13:10:49 +0100

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

>Sent: Tuesday, December 19, 2006 10:04 AM
>To: James M. Polk
>Cc: [email-masked]
>>> 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.
>>>
>> 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
>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 21 Dec 2006 10:33:53 -0500

James,
My assumption is that like with ECN, PCN (explicit pre-congestion
notification) information is carried in the IP header to the media
endpoint (receiver). The receivers are informed via PCN marking that
rate reduction is desirable. The receiver needs to signal to the
transmitter to reduce its sending rate. I was thinking for applications
that use RTP that RTCP could be used to signal rate changes between the
two media endpoint. 

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]
-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 4:08 PM
To: Babiarz, Jozef (CAR:0S03); Magnus Westerlund; [email-masked]
Subject: RE: [PCN] Alternatives to Preemption

Jozef

This is an interesting way of doing a solution, however, I do not see
what 
type of message is sent by the core edge to the actual phone to tell it
to 
do anything.  SIP messaging (with SDP inside) can and probably does take
an 
entirely different path to set up the call than the RTP media packets
take, 
therefore - something needs to be on the RTP path giving feedback.  This

could be RTCP, but is that sent by the core edge router? I don't believe
so 
(unless this node is also an SBC). Therefore, what does send this
message 
and what could it be in the form of?

I'm wondering if Magnus is assuming the ingress and egress of
bidirectional 
RTP pcakets traverse the same core edge router?

I'm not looking for a solution as much as I'm looking for what people
might 
be thinking a solution could look like.

> >resources gets overtaxed. Aren't there some cases when the
alternative
> >For example in cases when large parts of the traffic is voice, then
one

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Tue, 26 Dec 2006 10:46:30 -0600

Magnus,

You have asked an interesting question. ("Isn't most operator more in
favor of reduced quality, rather than dropped calls?")

I suspect that different users would have different preferences.

Personally, I would like a third choice. I don't like either dropped
calls or unacceptable QoS, as I suspect both would lead to service calls
resulting in no trouble found and thus subscriber disappointment with
the service. Rather I would be more comfortable with using the PCN to
cause new session originations to be blocked so that the network can
return to a stable state. I gathered at the BOF that this would likely
occur in a matter of several seconds after an event.

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

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 7:48 AM
To: [email-masked]
Subject: [PCN] Alternatives to Preemption

Hi,

than as a constraint.

Cheers

Magnus Westerlund