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

From: Michael Menth <[email-masked]>
Date: Tue, 10 Jul 2007 08:36:09 +0200

Hi,

I would like to start a discussion regarding the probing mechanism. I 
see the following constraints when equal-cost multipath (ECMP) routing 
is used:

1) Probe packets must have the same source and destination addresses as 
well as source and destination ports as normal data packets because load 
balancing algorithms compute a hash over relevant packet header entries 
and depending on this hash value, they forward the packets to one of 
several possible outgoing interfaces. This assures that all packets of 
the same flow take the same route.

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?

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.

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.

Are these assumptions correct? What mechanisms are possible?

Best wishes,

    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

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

---

From: <[email-masked]>
Date: Thu, 12 Jul 2007 12:23:49 +0100

Hi,

The points you make seem fair to me, however I have a couple of caveats.

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".

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?)

similarly the same set of options could be there for probing. The
probing option chosen for probing should either be the same as for
'normal' adm ctrl or a weaker one (stronger doesn't make sense). 

Secondly, we know (I think) from discussions over the last year or so
that dealing with ECMP is quite tricky. It would be nice not to require
complex things to be standardised /implemented. Currently the draft says
that "Probing functions are optional". For instance the operator might
not be using ecmp, or might not think it's a particular problem -
perhaps they're prepared to risk the rare wrong adm decision (the flow
termination mechanism handles such cases).  However, we should discuss
and think about how to deal with probing & ecmp more.

Thirdly, it would also be nice to have some scenario analysis /data of
how important this is (how often would probing be needed? How often
would ecmp lead to focussed overload instead of a reasonably balanced
traffic distribution?)

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?

Best wishes
phil

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]]
> Sent: 10 July 2007 07:36
> To: [email-masked]
> Subject: [PCN] Probing in the presence of hash-based load balancing
> 
> Hi,
>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 12 Jul 2007 23:54:20 -0400

Phil Eardley wrote on July 12, 2007.

>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.   

>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. 

>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
> "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.

> 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.
> 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. 

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: July 12, 2007 7:24 AM
To: [email-masked]; [email-masked]
Subject: RE: [PCN] Probing in the presence of hash-based load balancing

Hi,

Some options:

Best wishes
phil