Subject: FW: [PCN] Probing in the presence of hash-based load balancing

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 13 Jul 2007 09:05:45 +0200

Hi,

some comments in line, marked [Rudi].

>First, we shouldn't set harder requirements for probing than in the
>case where there is no probing. 
>Ie our assumption to date has been that probing is needed when there's
>not enough recent traffic between the specific PCN-ingress-node &
>PCN-egress-node (that the new flow would flow between), in order that
>we can make an accurate measurement-based admission decision. Note 
>this is traffic between the ingress & egress - it isn't "on the 
>specific ECMP path that the new flow would flow along".

[Joe]My assumption is that probing is needed under the following
conditions:
a)when there is no traffic between ingress-egress nodes for that
  aggregate,
b)when there may be ECMP or other methods that may provide multiple
  paths between ingress-egress nodes,
c)if there is a need to verify that real-time media packets once
  admitted can infect reach the egress node. 

[Rudi] Probing is only required if any border node of a PCN domain 
provides pre-congestion feedback. If that's the case, a) is required.
b) assumes ECMP "aware" probing. Phil mentioned ingress-egress above.
So Phil's thinking about some basic functionality while Joe's having 
a more advanced solution in mind (which is desireable, but harder 
to realise).
c) to me is not an aim, it is more something we can do it we 
realise a) and b). 

>Some options:
>- we could say the adm decision is made on basis of measured traffic
>  between the specific PCN-ingress-node & PCN-egress-node
>- we could say the adm decision is made on basis of measured traffic
>  along the specific ECMP path
>- we could leave this question open for the operator to decide (the
>  first is a MUST, the second is a MAY?)

[Joe]I think we better say that adm decision is made on basis of a
specific path. 

[Rudi]We can standardise an overly conservative solution if we agree 
on MUST for the first. It is up to a provider to improve the 
efficency of his operations and to ensure proper functionality of 
PCN. The standard must insist on proper functionality and should 
provide tools to improve efficiency. Looking at it from that angle, 
Phil's suggestion on MUST for the first and MAY for the second is 
allright.

>Lastly, re your point 4 below. This is a good question. I believe the
>answer isn't the same for all vendors. 
>One specific question [slightly off topic of your email, as related to
>ecmp rather than probing specifically]: are the DS field & ECN field
>considered by the ecmp hash algos? If yes, that could mean that a pkt
>would travel a different ecmp path after it gets PCN-marked compared to
>if it stays unmarked; I'm not sure if this has any nasty implications
>for us, but we ought to think about it?

[Joe]ECMP hash algorithms may use some or all of, source/destination IP
address, source/destination port numbers, protocol ID and DSCP field.
ECN field should not be used in hash algorithms.

Michael Menth wrote on 10 July 2007 07:36
> 2) PCN-based AC is a border-to-border solution. Therefore, PCN-related
> signaling packets should not leave the network although equipped with
> "wrong" source and destination addresses. Is that true? If not, why
> not?

[Joe]True. I believe that egress node would need to block from
forwarding to next node probe packets in a border-to-border scenario.

[Rudi] Agree to Joe and Michael.

> 3) A standardized mechanism is required to encode probe packets that
> PCN egress routers can recognize and intercept them, and to signal
> appropriate feedback to the corresponding AC entities.

[Joe]This is highly desirable. We need to define a probing method that
works with ECMP and egress router can easily detect probe packets.

[Rudi] Yes, that's desireable.

> 4) I don't know the exact header fields used for the hash-based load
> balancing. These fields should be the same for normal data packets and
> probe packets to make sure that they all take the same path. Which
> fields are typically used for that purpose? Those that are typically
> not  used might be changed to indicate that PCN packets are used for
> probing.

[Joe] I believe ECN field in IP header could be used to signal to egress
router that this packet needs further inspection. Upon further
inspection the egress router determines that it is a probe packet. 

[Rudi] By that you define a "selective RAO", meaning that egress nodes 
must interpret some IP header "codepoint" as RAO. The cool part of your 
idea is that only some routers interpret this "codepoint" as RAO, not 
all. Security demands to limit this option to a single domain of trust. 
So an egress node must act differently on a packet received with that 
codepoint, depending on the interface, where it is received (from 
within PCN domain or from a PCN external interface).
I like the idea. If more people provide support, we may contact 
the WG chairs to see how our chances are to get that standardised 
within IETF. I'm not sure, whether this is "just a PCN decision".
Working on this proposal should however not delay work on the easier 
to realise "ingress-egress" probing functionality.

Regards,

Ruediger

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

---

From: Michael Menth <[email-masked]>
Date: Fri, 13 Jul 2007 10:58:11 +0200

Hi,

I think designing a probing mechanism in such a way that it copes with 
ECMP is not too hard when we do that from scratch, but once we have 
defined just some mechanism which is not capable to do that, it will be 
very hard to extend it for that purpose. I don't think we want two 
different probing mechanisms, one which is ECMP-capable and another one 
with is not. Therefore, I would prefer to keep this goal in mind from 
the beginning of the design process.

Regards,

    Michael

-- 
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: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 20 Jul 2007 17:57:10 +0200

Hi all

Regarding the below issue!

> I don't think we want two different probing 
> mechanisms, one which is ECMP-capable and another one with is 
> not. Therefore, I would prefer to keep this goal in mind from 

I agree with Michael!

Best regards,
Georgios

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]] 
> Sent: vrijdag 13 juli 2007 10:58
> To: Geib, Ruediger
> Cc: [email-masked]
> Subject: Re: FW: [PCN] Probing in the presence of hash-based 
> load balancing
> 
> Hi,
> 
> I think designing a probing mechanism in such a way that it 
> copes with ECMP is not too hard when we do that from scratch, 
> but once we have defined just some mechanism which is not 
> capable to do that, it will be very hard to extend it for 
> that purpose. I don't think we want two different probing 
> mechanisms, one which is ECMP-capable and another one with is 
> not. Therefore, I would prefer to keep this goal in mind from 
> >> Ie our assumption to date has been that probing is needed when 
> >> there's not enough recent traffic between the specific 
> >> PCN-ingress-node & PCN-egress-node (that the new flow would flow 
> >> between), in order that we can make an accurate measurement-based 
> >> admission decision. Note this is traffic between the 
> ingress & egress 
> >> - it isn't "on the specific ECMP path that the new flow 
> would flow along".
> >>     
> >
> > So Phil's thinking about some basic functionality while 
> Joe's having a 
> > more advanced solution in mind (which is desireable, but harder to 
> > realise).
> > c) to me is not an aim, it is more something we can do it 
> we realise 
> > a) and b).
> >
> >   
> >> Some options:
> > on MUST for the first. It is up to a provider to improve 
> the efficency 
> > of his operations and to ensure proper functionality of PCN. The 
> > standard must insist on proper functionality and should 
> provide tools 
> > to improve efficiency. Looking at it from that angle, Phil's 
> > suggestion on MUST for the first and MAY for the second is allright.
> >
> >   
> >> One specific question [slightly off topic of your email, 
> as related 
> >> to ecmp rather than probing specifically]: are the DS field & ECN 
> >> field considered by the ecmp hash algos? If yes, that 
> could mean that 
> >> a pkt would travel a different ecmp path after it gets PCN-marked 
> >> compared to if it stays unmarked; I'm not sure if this has 
> any nasty 
> >> implications for us, but we ought to think about it?
> >>     
> >
> > [Joe]ECMP hash algorithms may use some or all of, 
> source/destination 
> > IP address, source/destination port numbers, protocol ID 
> and DSCP field.
> >> 2) PCN-based AC is a border-to-border solution. Therefore, 
> >> PCN-related signaling packets should not leave the network 
> although 
> >> equipped with "wrong" source and destination addresses. Is 
> that true? 
> >> If not, why not?
> >>     
> >
> >> balancing. These fields should be the same for normal data packets 
> >> and probe packets to make sure that they all take the same path. 
> >> Which fields are typically used for that purpose? Those that are 
> >> typically not  used might be changed to indicate that PCN 
> packets are 
> >> used for probing.
> >>     
> >
> > [Joe] I believe ECN field in IP header could be used to signal to 
> > egress router that this packet needs further inspection. 
> Upon further 
> > must interpret some IP header "codepoint" as RAO. The cool part of 
> > your idea is that only some routers interpret this 
> "codepoint" as RAO, 
> > not all. Security demands to limit this option to a single 
> domain of trust.
> > I like the idea. If more people provide support, we may 
> contact the WG 
> > chairs to see how our chances are to get that standardised within 
> > IETF. I'm not sure, whether this is "just a PCN decision".
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206