Subject: [PCN] Explicit PCN Marking

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 5 Mar 2007 11:02:06 -0500

I've submitted a draft proposing a method that can be used for marking
excess real-time traffic
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking-0
0.txt . Detailed simulations results can be found at
http://standards.nortel.com/pcn/Simulation_EPCN.pdf 

*  Abstract: 
In this document, we propose to the PCN WG for review, discussion and
evaluation of a method for marking real-time packets to indicate that
removal (preemption) of excess real-time traffic from the network is
needed. First, we define the marking behavior in the interior node
followed with a brief description of how this marking would work in the
edge-to-edge and application-control deployment models with simulations
results for different conditions and traffic mixes. Then, we discuss the
simulation results for voice, both constant rate and variable rate with
silence suppression, and variable rate MPEG-4 like video traffic with
large and small number of flows at the congestion point.

Regards, Joe
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]

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

---

From: Michael Menth <[email-masked]>
Date: Mon, 05 Mar 2007 19:23:27 +0100

Hi Joe,

I read the first half of your draft. The beginning of Section 2 is hard 
to read.

I have understood the proposed marking mechanism as follows. Instead of 
marking several consecutive packets in an intermediate router when its 
token bucket runs empty, you just mark a single packet and put x octets 
back into the token bucket to avoid that another x octets are going to 
be marked. The egress collects the marked packets and calculates the 
excess traffic rate for individual ingress-egress pairs taking into 
account the size of marked packets plus another x octects per packet.

As a result of this marking scheme is that less packets are marked.
-> they belong to fewer ingress gateways
-> fewer ingress gateways need to reduce their rate but by a larger amount.
Is that what you intend?

Best wishes,

Michael

Jozef Babiarz wrote:
>
> I’ve submitted a draft proposing a method that can be used for marking 
> excess real-time traffic 
> _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking-00.txt_ 
> . Detailed simulations results can be found at 
> _http://standards.nortel.com/pcn/Simulation_EPCN.pdf_
>
> · * Abstract:*
> followed with a brief description of how this marking would work in 
> the edge-to-edge and application-control deployment models with 
> simulations results for different conditions and traffic mixes. Then, 
> we discuss the simulation results for voice, both constant rate and 
> variable rate with silence suppression, and variable rate MPEG-4 like 
> video traffic with large and small number of flows at the congestion 
> point.
>
> ///Regards, Joe/
>
> ------------------------------------------------------------------------
>

-- 
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: "Jozef Babiarz" <[email-masked]>
Date: Mon, 5 Mar 2007 20:15:39 -0500

Hi Michael,  
The intent of Explicit PCN Marking approach is that the interior router
measures the excess traffic and marks a packet to indicate which flow
needs to be removed (terminated). Should not that in later phase of PCN
standardization a marked flow can also have its sending rate reduced
(rate adapted). The interior router marks a packet every x bytes of
traffic that is in excess of the supportable rate. So if it is important
to measure what the excess traffic is, the gateway counts the number of
marked packets received per ingress-egress aggregate over time where a
marked packet equals x bytes of excess traffic.

My intention is that with this marking, there is no need for the egress
or ingress gateways do any rate measurements of traffic or even counting
the number of marked packets received. The intent is the interior router
identifies the flow or flows that need their rate reduced. In the first
phase of the charter a marked flow would have its rate reduced to zero
(flow is terminated) but in later phase of PCN work a market flow could
have its sending rate reduced to a lower rate. The egress gateway
conveys to ingress gateway what flow needs its rate reduced.

Does this help?

Regards, Joe
Telephone: 613-763-6098 
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: March 5, 2007 1:23 PM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: Re: [PCN] Explicit PCN Marking

Hi Joe,

As a result of this marking scheme is that less packets are marked.
-> they belong to fewer ingress gateways
-> fewer ingress gateways need to reduce their rate but by a larger
amount.
Is that what you intend?

Best wishes,

Michael

> excess real-time traffic 
_http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking-
00.txt_ 
> * * Abstract:*

---

From: Michael Menth <[email-masked]>
Date: Tue, 06 Mar 2007 08:09:18 +0100

Dear Joe,

I see. The difference to the existing solution is: a single marked 
packet suffices that the egress signals to the ingress that the 
respective flow should be terminated. The marking is just used to 
identify flows to be terminated. The usual way, i.e., calculating the 
excess traffic rate for each ingress-egress aggregate at the egress, 
signaling it to the respective ingress such that the ingress can select 
the flows to be terminated, becomes a secondary option which would 
require egress routers to measure marked traffic again. Is that right?

Best wishes,

    Michael

---

From: Lars Eggert <[email-masked]>
Date: Tue, 6 Mar 2007 09:35:41 +0200

Hi,

On 2007-3-6, at 3:15, ext Jozef Babiarz wrote:
> needs to be removed (terminated).

without having read the draft yet (sorry, on my reading list for  
Prague), this extends at least what is my view of the chartered scope.

I had been under the impression that the decision about which flows  
were being admitted/terminated was a function that was (logically)  
located at the boundary routers, based on congestion markings from  
the interior. The semantics of these markings indicate some level of  
congestion, and the boundary can infer something about the state of  
the network by statistically analyzing the level of marked traffic to  
drive the admission/termination decision. This works with multiple  
congested routers along a path, which will result in a higher average  
marking rate.

In your model, at least the termination decision seems to happen at  
an interior router and it is only the enforcement of the decision  
that is delegated to the boundary. The markings have a much different  
semantics ("terminate this flow"). One issue I see is that the router  
that makes this decision has a much more limited view of the network  
than the boundary. Another issue is that some level of coordination  
between the interior routers seems to be needed, to result in a  
stable system.

Or am I misunderstanding something?

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 6 Mar 2007 08:53:06 -0500

Yes Michael, that is correct.

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: March 6, 2007 2:09 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: Re: [PCN] Explicit PCN Marking

Dear Joe,

Best wishes,

    Michael

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 6 Mar 2007 13:27:02 -0500

>congested routers along a path, which will result in a higher average  

The marking by the interior router needs to identify traffic (flows)
that are flowing through congested routers. If we assume there maybe
multiple paths between ingress and egress gateways than congestion
levels can also be at different levels. We do not what the ingress
gateway to terminate flows that are flowing through non-congested paths.
At least in my view the decision of what flows are terminated can be
performed in any boundary node egress or ingress however, ingress
boundary node needs to enforce the decision. 

>between the interior routers seems to be needed, to result in a  

In my model an interior router marking a packet (flow) that is an
indication to the edges (boundary nodes) that the marked flow is on a
congested path. The boundary nodes still need to act on this
information. In the original phase of the PCN work it the action is to
terminate the mark flow. In later phases, could do rate-adaptation, or
other action. Should not that the marking of packets continues (one
marked packet every x bytes of excess traffic) until congestion
condition is removed.

Regards, Joe
Telephone: 613-763-6098 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: March 6, 2007 2:36 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Explicit PCN Marking

Hi,

Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 7 Mar 2007 08:48:33 +0100

Jozef,

while your proposal indeed requires different functionalities 
compared to the PCN functionalities as discussed up to know, 
I must admit that it is a way to deal with backbone load 
balancing and cases of "unsymmetric congestion". Load balancing 
is likely to occur in backbone networks and PCN should work 
properly if IP load balancing is active. I think PCN should 
collect and discuss ideas like yours.

Regards,

Ruediger

|>In your model, at least the termination decision seems to happen at  
|>an interior router and it is only the enforcement of the decision  
|>that is delegated to the boundary. The markings have a much different

|>semantics ("terminate this flow"). One issue I see is that the router

|>that makes this decision has a much more limited view of the network  
|>than the boundary. Another issue is that some level of coordination  
|>between the interior routers seems to be needed, to result in a  
|>stable system.
|
|In my model an interior router marking a packet (flow) that is an
|indication to the edges (boundary nodes) that the marked flow is on a
|congested path. The boundary nodes still need to act on this
|information. In the original phase of the PCN work it the action is to
|terminate the mark flow. In later phases, could do rate-adaptation, or
|other action. Should not that the marking of packets continues (one
|marked packet every x bytes of excess traffic) until congestion
|condition is removed.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 7 Mar 2007 09:52:08 +0200

On 2007-3-6, at 20:27, ext Jozef Babiarz wrote:
> information.

Agreed - the meaning of the mark when set by a router is something  
like "this packet (and by inference, this flow) are contributing to  
(pre-)congestion." In your earlier email, the meaning was "terminate  
this flow, please", which is quite different - it's not a (pre-) 
congestion mark anymore, your mark prescribes a specific reaction.  
This moves the decision point from the boundary into the network.

> In the original phase of the PCN work it the action is to
> terminate the mark flow.

Not only. The boundary may also alleviate (pre-)congestion over time  
by not admitting new flows into the network. Especially when the  
marking volume establishes that the network is approaching congestion  
but hasn't reached that point yet, not admitting new flows into the  
domain may be the preferred reaction, because it doesn't interfere  
with established communication. I don't see how flow admission would  
happen based on your marking definition.

Lars

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 7 Mar 2007 08:02:34 -0500

Hi Ruediger, Jozef,

Yes, the ability to address ECMP directly is indeed a very attractive
point of Joe's proposal.

One of the other ideas that was discussed to address the ECMP case was
that PCN ingress could choose for preemption only those flows which have
already been pre-emption marked (based on the "usual" marking).  This
would prevent from pre-empting flows on the "unaffected" ECMP paths, but
potentially slow down the process of pre-empting enough flows on the
affected ones in some cases (specifically the cases when pre-emption
marking keeps affecting the same subset of affected flows rather than
being uniformly distributed among all affected flows). This would be
corrected in subsequent pre-emption round, though. 

It was discussed that this "preempted only marked flows" decision could
be a local decision at the ingress - part of selection of *which* flows
to choose at the ingress for pre-emption - something that the current cl
drafts leave up to the implementation. Implications may need to be
studied further.

Another idea that was discussed was to use additional "affected" marking
that would indicate that a packet would go through a bottleneck (the
idea earlier described in the context of RMD). Unfortunately needs yet
another codepoint.

Anna 

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 2:49 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] Explicit PCN Marking
> 
> Jozef,
> 
> balancing and cases of "unsymmetric congestion". Load 
> balancing is likely to occur in backbone networks and PCN 
> should work properly if IP load balancing is active. I think 
> PCN should collect and discuss ideas like yours.
> 
> Regards,
> 
> Ruediger
> 
> 
> |>In your model, at least the termination decision seems to 
> happen at an 
> |>interior router and it is only the enforcement of the 
> decision that is 
> |>delegated to the boundary. The markings have a much different
> 
> |>between the interior routers seems to be needed, to result 
> in a stable 
> |>system.
> |

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 7 Mar 2007 14:43:33 +0100

Hi Anna

I think it will be good if we can get some PCN-WG time slot(s) 
to present different possible solutions, not only associated with the ECMP 
issue but also on other PCN related issues,
that will make sense to be considered for further 
investigation within the PCN WG.

Best Regards,
Georgios

> From: Anna Charny (acharny) [mailto:[email-masked]] 
> Sent: woensdag 7 maart 2007 14:03
> To: Geib, Ruediger; [email-masked]
> Cc: [email-masked]
> Yes, the ability to address ECMP directly is indeed a very 
> attractive point of Joe's proposal.
> 
> One of the other ideas that was discussed to address the ECMP 
> case was that PCN ingress could choose for preemption only 
> those flows which have already been pre-emption marked (based 
> on the "usual" marking).  This would prevent from pre-empting 
> flows on the "unaffected" ECMP paths, but potentially slow 
> down the process of pre-empting enough flows on the affected 
> ones in some cases (specifically the cases when pre-emption 
> marking keeps affecting the same subset of affected flows 
> rather than being uniformly distributed among all affected 
> flows). This would be corrected in subsequent pre-emption 
> round, though. 
> 
> It was discussed that this "preempted only marked flows" 
> decision could be a local decision at the ingress - part of 
> selection of *which* flows to choose at the ingress for 
> pre-emption - something that the current cl drafts leave up 
> to the implementation. Implications may need to be studied further.
> 
> Another idea that was discussed was to use additional 
> "affected" marking that would indicate that a packet would go 
> through a bottleneck (the idea earlier described in the 
> context of RMD). Unfortunately needs yet another codepoint.
> 
> Anna 
> 
> > while your proposal indeed requires different 
> functionalities compared 
> > to the PCN functionalities as discussed up to know, I must 
> admit that 
> > it is a way to deal with backbone load balancing and cases of 
> > "unsymmetric congestion". Load balancing is likely to occur in 
> > backbone networks and PCN should work properly if IP load 
> balancing is 
> > active. I think PCN should collect and discuss ideas like yours.
> > 
> > Regards,
> > 
> > Ruediger
> > 
> >

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 7 Mar 2007 09:02:32 -0500

Hi Georgios,

We have requested a slot for the single-marking draft.  Joe has
requested a slot for his draft.  The cl-architercture draft lists all
sorts of open issues/questions already. Do you have anything specific in
addition to all of this in mind?  

Anna 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 8:44 AM
> To: Anna Charny (acharny); 'Geib, Ruediger'; [email-masked]
> Cc: [email-masked]
> I think it will be good if we can get some PCN-WG time 
> slot(s) to present different possible solutions, not only 
> associated with the ECMP issue but also on other PCN related 
> issues, that will make sense to be considered for further 
> > that PCN ingress could choose for preemption only those flows which 
> > have already been pre-emption marked (based on the "usual" 
> marking).  
> > This would prevent from pre-empting flows on the "unaffected" ECMP 
> > paths, but potentially slow down the process of pre-empting enough 
> > flows on the affected ones in some cases (specifically the 
> cases when 
> > pre-emption marking keeps affecting the same subset of 
> affected flows 
> > rather than being uniformly distributed among all affected flows). 
> > This would be corrected in subsequent pre-emption round, though.
> > 
> selection 
> > of *which* flows to choose at the ingress for pre-emption - 
> something 
> > that the current cl drafts leave up to the implementation. 
> > Implications may need to be studied further.
> > 
> > Another idea that was discussed was to use additional "affected" 
> > marking that would indicate that a packet would go through a 
> > bottleneck (the idea earlier described in the context of RMD). 
> > Unfortunately needs yet another codepoint.
> > 
> > Anna
> >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 7 Mar 2007 15:22:10 +0100

Hi Anna

Yes, I would like to present some possible solutions (in some slides) 
that are probably not discussed in the current PCN drafts!

Best regards,
Georgios

> Sent: woensdag 7 maart 2007 15:03
> To: Georgios Karagiannis; Geib, Ruediger; [email-masked]
> Cc: [email-masked]
> We have requested a slot for the single-marking draft.  Joe 
> has requested a slot for his draft.  The cl-architercture 
> draft lists all sorts of open issues/questions already. Do 
> you have anything specific in addition to all of this in mind?  
> 
> Anna 
> 
> associated 
> > with the ECMP issue but also on other PCN related issues, that will 
> > make sense to be considered for further investigation 
> within the PCN 
> > WG.
> > 
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > 
> >  
> >

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 7 Mar 2007 09:29:44 -0500

Hi georgios,

Is there a draft on these to take a look at?

Thanks,
Anna  

> Sent: Wednesday, March 07, 2007 9:22 AM
> Yes, I would like to present some possible solutions (in some 
> slides) that are probably not discussed in the current PCN drafts!
> 
> Best regards,
> Georgios
> 
>  
> 
> > sorts of open issues/questions already. Do you have 
> anything specific 
> > in addition to all of this in mind?
> > 
> > Anna
> > 
> "affected"

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 7 Mar 2007 15:39:30 +0100

Hi Anna

Not yet, but it will come after the IETF meeting!

Best regards,
Georgios

> Sent: woensdag 7 maart 2007 15:30

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 7 Mar 2007 10:37:54 -0500

Lars,
The Explicit PCN Marking is intended to be used for removal of excess
traffic (congestion) from the network. I agree that it is not suitable
to be used for admission control (blocking of new flows being admitted
into the network). For admission control, I'm currently doing
simulations of a method that is similar to what is documented in
draft-briscoe-tsvwg-cl-phb-03 section 2, however I'm using a token
bucket approach versus virtual queue. Simulation results are encouraging
for voice traffic, including controlling over admission during burst
call attempts. Will share my results once I've completed the work. 

Regards, Joe
Telephone: 613-763-6098 
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: March 7, 2007 2:52 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Explicit PCN Marking

Lars