Subject: [PCN] Classification of packets by ingress-egress-aggregate

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Jan 2012 11:03:02 -0500

As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has 
maintained that in the absence of tunneling or the use of the aggregate 
RSVP method for determining ingress-egress-aggregate classifiers, 
routing data are inadequate for the purpose. He points out the case 
where an upstream domain uses ECMP, so that the same microflow could 
enter the PCN domain through multiple ingress nodes and the egress node 
wouldn't be able to tell where it came from.

It appears, then, that the edge behaviour drafts will have to restrict 
their applicability to the cases where PCN paqackets are tunneled or 
where the aggregate RSVP method is used to create classifiers. (Even in 
the latter case, I'm not sure how Joel's upstream ECMP case is countered.)

Does anyone have a better idea here?

Tom Taylor

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 5 Jan 2012 16:30:43 +0000

I think we should put it the other way round. In networks that are using ECMP then PCN traffic has to be tunnelled or use suitable RSVP. That sort of matches with what it says in RFC5559 about tunnelling.

I'm no expert, but presumably RSVP must be able to cope with ECMP somehow? Otherwise the RESV message wouldn't be sure to return down the same route that the PATH message took?

Toby

On 5 Jan 2012, at 16:03, Tom Taylor wrote:

> As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has maintained that in the absence of tunneling or the use of the aggregate RSVP method for determining ingress-egress-aggregate classifiers, routing data are inadequate for the purpose. He points out the case where an upstream domain uses ECMP, so that the same microflow could enter the PCN domain through multiple ingress nodes and the egress node wouldn't be able to tell where it came from.
> 
> It appears, then, that the edge behaviour drafts will have to restrict their applicability to the cases where PCN paqackets are tunneled or where the aggregate RSVP method is used to create classifiers. (Even in the latter case, I'm not sure how Joel's upstream ECMP case is countered.)
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Thu, 05 Jan 2012 12:39:18 -0400

On 05.01.2012 12:30, Toby Moncaster wrote:

> I think we should put it the other way round. In networks that are
> using ECMP then PCN traffic has to be tunnelled or use suitable RSVP.
> That sort of matches with what it says in RFC5559 about tunnelling.

I thought we had all reached this conclusion about 3 years ago...

> I'm no expert, but presumably RSVP must be able to cope with ECMP
> somehow? Otherwise the RESV message wouldn't be sure to return down
> the same route that the PATH message took?

My recollection is that in classic RSVP, RESV messages are forwarded 
upstream based on intermediate node PATH state, not via normal 
forwarding.  But in a PCN network we would only be interested in some 
form of aggregated RSVP, where PATH/RESV state is only installed on the 
domain boundaries (otherwise PCN would be kind of pointless).

Regards,

// Steve

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jan 2012 14:32:03 -0600

At 10:39 AM 1/5/2012, Steven Blake wrote:
>upstream based on intermediate node PATH state, not via normal forwarding.

the above is a fact.

James

>But in a PCN network we would only be interested in some form of 
>aggregated RSVP, where PATH/RESV state is only installed on the

---

From: <[email-masked]>
Date: Fri, 6 Jan 2012 09:13:40 +0100

Hi Tom,

some kind of tunnel which is avoiding ECMP routing is the only
solution coming to my mind. L2TPv3 or Ethernet PWs (without
Flow Aware Transport) are some potential solutions.

We had statements saying that the WG doesn't deal with the issue
in earlier drafts. That's not good, it's honest however.

RSVP tunnels didn't support ECMP some years ago. But statements
on carrier class RSVP features should be made from someone who
knows the current deployments.

A fair question to answer may be, whether ECMP routing is a
commodity. If the reply is "yes", PCN based admission control
only makes sense if it is able to deal with ECMP.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Thursday, January 05, 2012 5:03 PM
To: pcn
Subject: [PCN] Classification of packets by ingress-egress-aggregate

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Fri, 06 Jan 2012 11:07:14 -0500

On your final point: Joel said that ECMP is a standard part of the 
operator's toolkit these days, so we do have a problem. I could see 
rethinking the theory of PCN to allow for ECMP, but it means taking a 
long step backwards in the process.

---

From: <[email-masked]>
Date: Fri, 6 Jan 2012 17:57:51 +0000

Dear all

I  agree with Toby. Some solutions are listed in the below draft (Section 5.1):
http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture-04 

I think that the solution that will work in PCN is tunelling. 
In particualr, in networks that are using ECMP then PCN traffic need to be tunnelled. In this case the  destination address (and so on) seen by the ECMP algorithm is that  of the PCN-egress-node, so all flows follow the same path. 
Effectively ECMP is turned off. As a compromise, to try to retain some of the benefits of ECMP, there could be several tunnels, each following a different ECMP path, with flows randomly assigned to different tunnels.  

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens Toby Moncaster [[email-masked]]
Verzonden: donderdag 5 januari 2012 17:30
Aan: Tom Taylor
CC: pcn
Onderwerp: Re: [PCN] Classification of packets by ingress-egress-aggregate

Toby

---

From: <[email-masked]>
Date: Tue, 10 Jan 2012 08:48:32 +0100

Hi Georgios,

a statement that tunnels avoiding flow based ECMP routing
is the way to go, I agree. I suggest to formulate it
that way, as there are tunnels which still support flow
based ECMP routing (like IP over LDP based MPLS or
Flow aware Transport).

We shouldn't mention multiple tunnels as a solution
enabling ECMP usage with PCN, if this results in an
expectation that we have to provide details how that
works.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 06, 2012 6:58 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate

Dear all

Best regards,
Georgios

Toby

---

From: Michael Menth <[email-masked]>
Date: Tue, 10 Jan 2012 11:16:34 +0100

Hi Georgios,

the use of the existing PCN variant work from a functional point of view 
as suggested by Ruediger. However, the defined PCN-based admission 
control mechanism may be inefficient in ECMP networks as early blocking 
is possible.

-> Section IV.7 in [MeLe12] M. Menth and F. Lehrieder: Performance of 
PCN-Based Admission Control under Challenging Conditions, accepted for 
IEEE/ACM Transactions on Networking, 2012
http://atlas2.informatik.uni-tuebingen.de/menth/papers/Menth08-Sub-8.pdf

This hint should be added as a caveat.

Regards,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: <[email-masked]>
Date: Tue, 10 Jan 2012 10:57:51 +0000

Hi Michael,

Agree, thank you very much! 
Can you please provide the text that we should include in the draft?

Best regards,
Georgios

> From: Michael Menth [mailto:[email-masked]]
> Sent: dinsdag 10 januari 2012 11:17
> To: Karagiannis, G. (Georgios)
> Cc: [email-masked]; [email-masked]
> the use of the existing PCN variant work from a functional point of view as
> suggested by Ruediger. However, the defined PCN-based admission control
> mechanism may be inefficient in ECMP networks as early blocking is possible.
> 
> IEEE/ACM Transactions on Networking, 2012 http://atlas2.informatik.uni-
> tuebingen.de/menth/papers/Menth08-Sub-8.pdf
> 
> > a statement that tunnels avoiding flow based ECMP routing is the way
> > to go, I agree. I suggest to formulate it that way, as there are
> > tunnels which still support flow based ECMP routing (like IP over LDP
> > based MPLS or Flow aware Transport).
> >
> > We shouldn't mention multiple tunnels as a solution enabling ECMP
> > usage with PCN, if this results in an expectation that we have to
> > provide details how that works.
> >
> > Regards,
> >
> > Ruediger
> >
> > In particualr, in networks that are using ECMP then PCN traffic need to be
> tunnelled. In this case the  destination address (and so on) seen by the ECMP
> algorithm is that  of the PCN-egress-node, so all flows follow the same path.
> > Effectively ECMP is turned off. As a compromise, to try to retain some of
> the benefits of ECMP, there could be several tunnels, each following a
> different ECMP path, with flows randomly assigned to different tunnels.
> >
> > Best regards,
> > Georgios
> >
> > Van: [email-masked] [[email-masked]] namens Toby
> Moncaster
> > [[email-masked]]
> > I think we should put it the other way round. In networks that are using
> ECMP then PCN traffic has to be tunnelled or use suitable RSVP. That sort of
> matches with what it says in RFC5559 about tunnelling.
> >
> maintained that in the absence of tunneling or the use of the aggregate RSVP
> method for determining ingress-egress-aggregate classifiers, routing data are
> inadequate for the purpose. He points out the case where an upstream
> domain uses ECMP, so that the same microflow could enter the PCN domain
> through multiple ingress nodes and the egress node wouldn't be able to tell
> where it came from.
> >>
> >> It appears, then, that the edge behaviour drafts will have to
> >> restrict their applicability to the cases where PCN paqackets are
> >> tunneled or where the aggregate RSVP method is used to create
> >> classifiers. (Even in the latter case, I'm not sure how Joel's
> >> upstream ECMP case is countered.)
> >>

---

From: Michael Menth <[email-masked]>
Date: Tue, 10 Jan 2012 13:40:40 +0100

Hi Georgios,

here is the requested text.

"The use of CL/SM's PCN-based admission control in networks with 
flow-based ECMP routing raises performance concerns. If one of multiple 
potential paths of an ingress-egress aggregate is pre-congested, 
admission control possibly blocks all further flows for this 
ingress-egress aggregate even though these flows are forwared over 
non-pre-congested paths. As a consequence, the defined PCN-based 
admission control mechanism may be inefficient as early blocking is 
possible [Section IV.7 in MeLe12]."

[MeLe12] M. Menth and F. Lehrieder: Performance of PCN-Based Admission 
Control under Challenging Conditions, accepted for IEEE/ACM Transactions 
on Networking, 2012

[MeLe12] is already cited in CL and SM in different context, so the 
reference is already available.

Regards,

     Michael