Subject: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

From: <[email-masked]>
Date: Wed, 16 Jul 2008 18:03:01 +0100

http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt 

Would like this draft to be WG doc towards WG milestone on marking
behaviour. Think there are actually only a few minor issues to clear up,
ie doc is nearly done]. So am trying to clear them up before ietf.

Have separated each Issue into a separate email. They're mainly prompted
by Joe's comments.

This is 1st of several emails to try & close Open Issues on
http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt 

Do we suggest downgrading as a possible traffic conditioning action or
not? (traffic conditioning on all links in PCN-domain, including on
PCN-ingress-node - where something special /different might be done).

Currently the draft says "if needed, then drop or downgrade pkts" (ie
downgrade to a lower priority behaviour aggregate)

As joe points out:

- the danger of downgrading is that pkts in a flow could get
mis-ordered. So there's an argument for not giving this as a
possibility. Or should downgrading be allowed as a possibility, but just
mention the danger? what's done in real diffserv /mpls networks today?

- an additional possible traffic conditioning action by the
PCN-ingress-node is to downgrade a *flow* (ie all pkts in a flow put
into lower BA). This seems a good thing to add to me. 

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

---

From: ken carlberg <[email-masked]>
Date: Thu, 17 Jul 2008 15:17:24 -0400

Phil,

> behaviour. Think there are actually only a few minor issues to clear  
> up, ie doc is nearly done]. So am trying to clear them up before ietf.
> Have separated each Issue into a separate email. They’re mainly  
> prompted by Joe’s comments.
>
> This is 1st of several emails to try & close Open Issues on http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt
>
> Do we suggest downgrading as a possible traffic conditioning action  
> or not? (traffic conditioning on all links in PCN-domain, including  
> on PCN-ingress-node – where something special /different might be  
> done).

I would like to advocate the position of yes.  let's allow for the  
possibility of downgrading.

> Currently the draft says “if needed, then drop or downgrade  
> pkts” (ie downgrade to a lower priority behaviour aggregate)
> As joe points out:
> - the danger of downgrading is that pkts in a flow could get mis- 
> ordered. So there’s an argument for not giving this as a possibility.

while mis-ordered packets is not a subject to be ignored, the primary  
concern stems from the degree or variance in which packets (and in  
particular, packets of a flow) are mis-ordered.  wide variations can  
emulate packet loss -- obviously, a bad thing.  but these conditions,  
as far as i know, mostly come up in outlier scenarios found in mobile  
nodes crossing admin boundaries and different foreign agents.

back in the mid-90's, UCL did some work with packet interweaving  
(purposely misordered packets) and found that end user quality of  
audio packets was actually better in the presence of packet loss,  
since packet drops at congestion points tend to be a bit bursty.   
point being that a bit of misordering of packets isn't something to be  
scared of.

> Or should downgrading be allowed as a possibility, but just mention  
> the danger?

I'd be comfortable with a note indicating the potential condition of  
misordering and leave it at that.

> what’s done in real diffserv /mpls networks today?
> - an additional possible traffic conditioning action by the PCN- 
> ingress-node is to downgrade a *flow* (ie all pkts in a flow put  

I'd advocate yes.

-ken

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 21 Jul 2008 23:20:00 -0400

Downgrading should only be done per flow and at ingress to PCN domain.
PCN mechanism should not cause packet mis-ordering.

By downgrading means that admission control is not performed for that
flow, DSCP value is changed at ingress to network and network if
congested will drop packets belonging to that flow. Should not that
downgrading needs to be performed before the flow is admitted into the
network.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: July 16, 2008 1:03 PM
To: [email-masked]
Subject: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

As joe points out:

---

From: Michael Menth <[email-masked]>
Date: Tue, 22 Jul 2008 07:14:27 +0200

I agree.

Michael

Jozef Babiarz wrote:
> /Regards, Joe/
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of [email-masked]
> *Sent:* July 16, 2008 1:03 PM
> *To:* [email-masked]
> *Subject:* [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01
>
> This is 1^st of several emails to try & close Open Issues on 
> PCN-ingress-node – where something special /different might be done).
>
> Currently the draft says “if needed, then drop or downgrade pkts” (ie 
> mis-ordered. So there’s an argument for not giving this as a 
> possibility. Or should downgrading be allowed as a possibility, but 
> just mention the danger? what’s done in real diffserv /mpls networks 
> today?
>
> PCN-ingress-node is to downgrade a **flow** (ie all pkts in a flow put 
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: ken carlberg <[email-masked]>
Date: Tue, 22 Jul 2008 08:41:26 -0400

On Jul 21, 2008, at 11:20 PM, Jozef Babiarz wrote:

> Downgrading should only be done per flow and at ingress to PCN  
> domain. PCN mechanism should not cause packet mis-ordering.
> By downgrading means that admission control is not performed for  
> that flow, DSCP value is changed at ingress to network and network  
> if congested will drop packets belonging to that flow. Should not  
> that downgrading needs to be performed before the flow is admitted  
> into the network.

interesting.  so the expectation is that a PCN domain will perform  
admission control on *all* ingress flows, and no flow(s) will be  
treated (segmented, traffic engineered) as best effort.  I think that  
approach is a bit idealistic, but perhaps our respective experiences  
with ISPs is different.

also, if we take the concern about mis-ordering one step further, I  
assume you would highly discourage the use of ECMP in the PCN domain  
because even though its out of scope of PCN as part of a solution, it  
can cause packet mis-ordering.

cheers,

-ken

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 18:55:29 +0100

ken
it's expected that there'll be traffic that isnt PCN within the PCN-domai (if i get your comment!).
 
as i understand it, all pkts in a flow follow the same ecmp path, so there shouldnt be any misordering.
 
thanks
phil

From: ken carlberg [mailto:[email-masked]]
Sent: Tue 22/07/2008 13:41
To: Jozef Babiarz
Cc: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

	
	Downgrading should only be done per flow and at ingress to PCN domain. PCN mechanism should not cause packet mis-ordering.
	By downgrading means that admission control is not performed for that flow, DSCP value is changed at ingress to network and network if congested will drop packets belonging to that flow. Should not that downgrading needs to be performed before the flow is admitted into the network.

interesting.  so the expectation is that a PCN domain will perform admission control on *all* ingress flows, and no flow(s) will be treated (segmented, traffic engineered) as best effort.  I think that approach is a bit idealistic, but perhaps our respective experiences with ISPs is different.

also, if we take the concern about mis-ordering one step further, I assume you would highly discourage the use of ECMP in the PCN domain because even though its out of scope of PCN as part of a solution, it can cause packet mis-ordering.

cheers,

-ken

---

From: ken carlberg <[email-masked]>
Date: Tue, 22 Jul 2008 14:56:07 -0400

Phil,

> domai (if i get your comment!).

ok, we're in sync on that point.  I just feel uncomfortable removing  
the option to downgrade packets in favor of dropping them given that a  
portion of a node's/link's resources is more than likely set aside for  
best effort, especially if the motivating factor for dropping is the  
*potential* for mis-ordering.  if folks feel strongly for recommending  
a policy of dropping, fine.  But I'd just like to point to down- 
grading as an option to consider.

> there shouldnt be any misordering.

my understanding is that this is configuration/implementation  
dependent.  otherwise, I don't think we'd  see documents like rfc-4928  
(avoiding ECMP treatment in MPLS networks) spring up.

cheers,

-ken

> treated (segmented, traffic engineered) as best effort.  I think  
> that approach is a bit idealistic, but perhaps our respective  
> experiences with ISPs is different.
>
> because even though its out of scope of PCN as part of a solution,  
> it can cause packet mis-ordering.
>
> cheers,
>
> -ken
>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 22 Jul 2008 19:11:39 -0400

Ken, properly designed ECMP mechanism normally do not cause packet
mis-ordering as the route selection is done on the first packet of a new
flow.

If route changes after a flow has started, than yes there is the
possibility that mis-ordering of packets may occur. In my view rerouting
of flows or downgrading once a flow has started should be an infrequent
event, like when link or node failures. I'm note say that mis-ordering
of packets dose not happen in the Internet all I trying to say is that
IETF should develop protocols and procedures that minimize the
possibility of packet mis-ordering. 

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: ken carlberg [mailto:[email-masked]] 
Sent: July 22, 2008 8:41 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

interesting.  so the expectation is that a PCN domain will perform
admission control on *all* ingress flows, and no flow(s) will be treated
(segmented, traffic engineered) as best effort.  I think that approach
is a bit idealistic, but perhaps our respective experiences with ISPs is
different.

cheers,

-ken

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 22 Jul 2008 19:30:22 -0400

Ken,
What I was trying to say that if the PCN class is fully utilized, than
new flows can be downgraded and use best effort. This means PCN
treatment will not be applied to these packets including admission
control. PCN based admission control should limit the amount of traffic
into the PCN domain so that there is no reason to perform downgrading of
flows once admitted, except under failure conditions, which I would
prefer that we let flow termination address that condition. Under
failure conditions most likely the best effort class will also be
congested. Also having two mechanisms downgrading and flow termination
working independently could bring instability into the system.  

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: July 22, 2008 2:56 PM
To: [email-masked]
Cc: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

Phil,

cheers,

-ken

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 23 Jul 2008 09:18:34 +0200

Joe,

I'm not sure whether your proposal is a good idea. What I've 
heard, QoS traffic is supposed to be accounted on incoming 
interfaces. Now allowing a peer to demote PCN to Best Effort 
opens the door for a misuse: incoming traffic is accounted 
and charged as PCN and then demoted to BE (due to a "temporal"
lack of PCN resources, of course). Allowing for this may 
prevent deployment of PCN accross multiple domains if the 
origin never learns that PCN transport is only 
partially available. 

The requirement would then be, that if PCN transport 
can't be used due to temporal lack of PCN resources in one 
domain along the end to end path, then it shouldn't be used 
at all. 
I also figure out that accounting get's rather complex if 
temporal availability of valued added PCN transport along 
different PCN enabled domains of an end to end path has to 
be respected. Formulated differently: how to sell QoS if a 
traffic of a user session crosses three domains and each 
domain may but must not deliver the traffic of that 
session with PCN transport?

Indicating "network busy" should be the aim if the PCN 
resources are fully utilised. The user should then have 
the option to set up his session with another transport 
quality, but that's entirely a matter of the service 
he's using (and not a matter decided by the transport 
provider).

So all in all, I don't look at demotion to Best Effort 
as a good idea unless it is signaled on service level. 
The latter may require similar signaling and layer 
interaction features as termination. Should that be 
the case, then demotion to Best Effort may be discussed 
in that context.

Regards,

Rudiger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Jozef Babiarz
Gesendet: Mittwoch, 23. Juli 2008 01:30
An: ken carlberg; [email-masked]
Cc: [email-masked]
Betreff: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

Ken,

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: July 22, 2008 2:56 PM
To: [email-masked]
Cc: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

Phil,

cheers,

-ken

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Sat, 26 Jul 2008 08:58:57 +0200

Hi

Going through the flood of emails after the vacation so I may not have
picked up the main issue here. 

I guess reordering and the severity depends on the appliation of the
transport. For instance some TCP implementations does not work well with
reordering. 
For UDP the severity of this issue depends more or less on the
implementation in the receiver. If the jitterbuffer is well implemented
and has the ability to adapt fairly fast, the user will only expect a
larger delay (as long as the receiver jitter buffer does not overflow).
In this case reordering is not a big issue, there are however a few
"if"s and "but"s and I don't believe that one can in general say that
reordeing is not an issue. I do however believe that reordering is
better that packet drop.

/Ingemar 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ken carlberg
> Sent: den 22 juli 2008 20:56
> > it's expected that there'll be traffic that isnt PCN within 
> the PCN- 
> > domai (if i get your comment!).
> 
> ok, we're in sync on that point.  I just feel uncomfortable 
> removing the option to downgrade packets in favor of dropping 
> them given that a portion of a node's/link's resources is 
> more than likely set aside for best effort, especially if the 
> motivating factor for dropping is the
> *potential* for mis-ordering.  if folks feel strongly for 
> recommending a policy of dropping, fine.  But I'd just like 
> to point to down- grading as an option to consider.
> 
> > as i understand it, all pkts in a flow follow the same ecmp 
> path, so 
> > there shouldnt be any misordering.
> 
> dependent.  otherwise, I don't think we'd  see documents like 
> rfc-4928 (avoiding ECMP treatment in MPLS networks) spring up.
> 
> cheers,
> 
> -ken
> 
> 
> >
> > thanks
> > phil
> >

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sat, 26 Jul 2008 17:13:29 -0400

Ruediger, see my comment below.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: July 23, 2008 3:19 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: AW: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

Joe,

I'm not sure whether your proposal is a good idea. What I've 
heard, QoS traffic is supposed to be accounted on incoming 
interfaces. Now allowing a peer to demote PCN to Best Effort 
opens the door for a misuse: incoming traffic is accounted 
and charged as PCN and then demoted to BE (due to a "temporal"
lack of PCN resources, of course). Allowing for this may 
prevent deployment of PCN across multiple domains if the 
origin never learns that PCN transport is only 
partially available.
[Joe] You raised a valid point. I was assuming that if a flow was going to be downgraded, it would be at flow admission time and admission control signalling would know about it.  

[Joe] Agree. If a new call is blocked from entering the PCN domain, application signalling could try a second time. This time using Best Effort or a service class that does not support PCN.    

[Joe] In full agreement with the above method of operation.

Regards,

Rudiger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Jozef Babiarz
Gesendet: Mittwoch, 23. Juli 2008 01:30
An: ken carlberg; [email-masked]
Cc: [email-masked]
Betreff: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

Ken,

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: July 22, 2008 2:56 PM
To: [email-masked]
Cc: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: Re: [PCN] Issue 1 on draft-eardley-pcn-marking-behaviour-01

Phil,

cheers,

-ken