Subject: RE: [PCN] PCN architecture, revised sub-section on probing

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Sep 2007 09:24:10 +0200

Phil,
 
my views on the subject:
 
- the discussion on the decision when to apply probing misses one
important aspect, at least if 
  you look at a single domain: probing is only required if any
pre-congestion occurs within this 
  domain. If there's no pre congested link within a domain, no probing
is required within this 
  domain. 
 
- given that probing is only applied within a domain, if there's
pre-congestion on any link, then 
  the only purpose of probing is to find out, whether traffic from the
particular ingress to a 
  desired egress would contribute to this pre-congestion. The probing
flow then should be 
  designed to ensure that packets of the probing flow are marked (and if
interpretation is 
  to be as simple as possible: marked probing packets mean no
admission). 
 
- If there's no flow between an ingress and an egress and ECMP is
operational within a 
  domain, the ingress may have to signal its intention to probe to an
egress.
 
I'm not sure whether a useful probing mechanism is easy to develop an
therefore support 
your proposal to regard probing as optional (at least in the single
domain case).
 
Regards,
 
Ruediger
 
 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 09, 2007 12:15 AM
To: [email-masked]
Subject: [PCN] PCN architecture, revised sub-section on probing

This is to flag up that I wrote a revised sub-section (in Section 5,
Detailed functional architecture) about probing. to reflect (hopefully!)
some other discussion we had on the list in july. 

5.5.  Probing functions

   Probing functions are optional, and can be used for admission

   control.  A PCN-ingress-node generates and sends probe packets in

   order to test the pre-congestion level.  Probing is useful or even

   essential under the following conditions:

   o  when an ingress-egress-aggregate carries no traffic (or too little

      traffic for the PCN-egress-node to accurately make the

      "measurements of PCN-traffic" that are required for an admission

      decision).  It may be that the traffic levels on other ingress-

      egress-aggregates are so high that a new flow shouldn't be

      admitted on the 'empty' ingress-egress-aggregate.  Probing is

      useful to check this.

   o  in the presence of multipath routing (ECMP) between the PCN-

      boundary-nodes, when some paths are pre-congested there may be

      other paths which aren't pre-congested.  Probing is useful to

      determine whether the new flow would follow a path that isn't pre-

      congested and hence can be admitted.

   Probe packets may be simple data addressed to the PCN-egress-node and

   require no protocol standardisation, although there will be best

   practice for their number, size and rate.  There are two

   possibilities for how probing is triggered:

   o  the PCN-egress-node requests (signals) the PCN-ingress-node to

      generate probe traffic

   o  if the PCN-ingress-node knows which PCN-egress-node is associated

      with the destination address in the admission request, then the

      PCN-ingress-node could know it has no reservation with that PCN-

      egress-node and unilaterally start probing.

   The probing functions are:

   o  Make decision that probing is needed

   o  (if required) Communicate the request that probing is needed - the

      PCN-egress-node signals to the PCN-ingress-node that probe traffic

      is needed

   o  Generate probe traffic - the PCN-ingress-node generates the probe

      traffic.  The appropriate number (or rate) of probe packets will

      depend on the PCN-marking algorithm; for example an excess-rate-

      marking algorithm generates fewer PCN-marks than a threshold-

      marking algorithm.

   o  Forward probe packets - as far as PCN-interior-nodes are

      concerned, probe packets must be handled the same as (ordinary

      data) PCN-packets.

   o  Consume probe packets - the PCN-egress-node consumes probe packets

      to ensure that they don't travel beyond the PCN-domain.

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

---

From: <[email-masked]>
Date: Mon, 24 Sep 2007 15:53:24 +0100

Thanks Ruediger

I'm not sure from your email whether you think that any changes or
additions are needed to the text in the draft, or whether it's ok.
Please let me know if you think something needs changing

Thanks!

phil 

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: 19 September 2007 08:24
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, revised sub-section on probing

Phil,

my views on the subject:

  domain. 

Regards,

Ruediger

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 09, 2007 12:15 AM
To: [email-masked]
Subject: [PCN] PCN architecture, revised sub-section on probing

	This is to flag up that I wrote a revised sub-section (in
Section 5, Detailed functional architecture) about probing. to reflect
(hopefully!) some other discussion we had on the list in july. 

	5.5.  Probing functions

	   control.  A PCN-ingress-node generates and sends probe
packets in

	   order to test the pre-congestion level.  Probing is useful or
even

	   o  when an ingress-egress-aggregate carries no traffic (or
too little

	      "measurements of PCN-traffic" that are required for an
admission

	      decision).  It may be that the traffic levels on other
ingress-

	      admitted on the 'empty' ingress-egress-aggregate.  Probing
is

	      useful to check this.

	   o  in the presence of multipath routing (ECMP) between the
PCN-

	      boundary-nodes, when some paths are pre-congested there
may be

	      other paths which aren't pre-congested.  Probing is useful
to

	      determine whether the new flow would follow a path that
isn't pre-

	   Probe packets may be simple data addressed to the
PCN-egress-node and

	   require no protocol standardisation, although there will be
best

	   o  the PCN-egress-node requests (signals) the
PCN-ingress-node to

	      generate probe traffic

	   o  if the PCN-ingress-node knows which PCN-egress-node is
associated

	      with the destination address in the admission request,
then the

	      PCN-ingress-node could know it has no reservation with
that PCN-

	   o  (if required) Communicate the request that probing is
needed - the

	      PCN-egress-node signals to the PCN-ingress-node that probe
traffic

	      is needed

	   o  Generate probe traffic - the PCN-ingress-node generates
the probe

	      traffic.  The appropriate number (or rate) of probe
packets will

	      depend on the PCN-marking algorithm; for example an
excess-rate-

	      marking algorithm generates fewer PCN-marks than a
threshold-

	      marking algorithm.

	      concerned, probe packets must be handled the same as
(ordinary

	      data) PCN-packets.

	   o  Consume probe packets - the PCN-egress-node consumes probe
packets

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 26 Sep 2007 08:31:41 +0200

Hi Phil,
 
the views I express should be added to the description on probing. 
 
Regards,
 
Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 24, 2007 4:53 PM
To: Geib, Rudiger
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, revised sub-section on probing

Thanks Ruediger

Thanks!

phil 

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: 19 September 2007 08:24
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, revised sub-section on probing

Phil,

my views on the subject:

  domain. 

Regards,

Ruediger

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 09, 2007 12:15 AM
To: [email-masked]
Subject: [PCN] PCN architecture, revised sub-section on probing

5.5.  Probing functions

      useful to check this.

      generate probe traffic

      is needed

      marking algorithm.

      data) PCN-packets.

---

From: <[email-masked]>
Date: Fri, 28 Sep 2007 18:30:19 +0100

Ruediger,

Follow-ups (further questions!) in-line on each of your 3 points 

[RG] - the discussion on the decision when to apply probing misses one
important aspect, at least if 

  domain. 

[phil] I slightly re-phrased the first bullet (the second bullet is
unaltered), so the text now says:

Probing is useful or even essential under the following conditions:

   o  when an ingress-egress-aggregate carries no traffic (or too little
traffic for the PCN-egress-node to accurately make the "measurements of
PCN-traffic" that are required for an admission decision), but the
traffic levels on other ingress-egress-aggregates are so high that a new
flow shouldn't be admitted on the 'empty' ingress-egress-aggregate.
Probing is useful to check this.

   o  in the presence of multipath routing (ECMP) between the
PCN-boundary-nodes, when some paths are pre-congested there may be other
paths which aren't pre-congested.  Probing is useful to determine
whether the new flow would follow a path that isn't pre-congested and
hence can be admitted.

I think what's written implies that it may not always be possible to
know whether there's any (relevant) pre-congestion or none - so there's
an argument for probing in such times of doubt to discover what the
situation really is (if it turns out that there isn't any pre-congestion
then, as you say, in some ways the probing hasn't proved to be useful).
I think the tweaked text above captures this, but please suggest any
mods to make it clearer (or disagree!)

[RG} - given that probing is only applied within a domain, if there's
pre-congestion on any link, then 

[phil] I'm not quite sure what you mean by "designed to ensure that
packets of the probing flow are marked". The section currently says that
probe pkts are handled in the same way as (ordinary data) PCN-pkts [*].
I think you may be suggesting something different, that probing pkts
should be preferentially PCN-marked? 

[*] incidentally, I'll tweak the text to add something like "in terms of
pkt scheduling/forwarding and PCN-marking" ; for pkt dropping it may be
arguable you should preferentially drop probes to ease DoS worries?

Re: "interpretation is to be as simple as possible: marked probing
packets mean no admission" - I think this is too solution-space for this
Architecture draft (presumably there may be different options, eg block
call if the single probe pkt is marked, if at least 2 out of 100 marked,
etc)

[RG] - If there's no flow between an ingress and an egress and ECMP is
operational within a 

[phil] could you explain your reference to ECMP please?

At the moment the doc says that "(if required) Communicate the request
that probing is needed - the PCN-egress-node signals to the
PCN-ingress-node that probe traffic is needed". But you're suggesting
there are particular circumstances when something is needed in the
opposite direction?

Thanks!

phil

---

From: Steven Blake <[email-masked]>
Date: Fri, 28 Sep 2007 14:15:34 -0400

If a probe packet for a PCN-managed flow is intended to follow the same
ECMP path as the flow, then the probe packet has to look exactly like
flow packets in the header fields usually hashed by routers to load
split for ECMP: IP source/destination address, TCP/UDP
source/destination port; maybe the protocol/next header field as well.

If you do this, you are essentially spoofing traffic for the host
originating the flow.  I'm sure the security review comments for this
will make for entertaining reading.

At the very least, you need to ensure that there is an *airtight*
mechanism for ensuring that the probe traffic can never leak out of the
PCN domain, and that no ICMP traffic can be sent back towards the
host.  

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: Lars Eggert <[email-masked]>
Date: Sat, 29 Sep 2007 09:31:03 +0300

> PCN domain, and that no ICMP traffic can be sent back towards the

Let me add that probe traffic (other than for supporting ECMP) seems  
only useful when a domain can go from "no congestion" to "must  
terminate" through the admission of a very small number of flows.  
Otherwise, the gradual admission of regular flows can be used to  
determine whether admission should be terminated. In other words,  
regular flows can be used to "probe" the domain.

I question whether domains that require explicit probing mechanisms  
fall under the current PCN charter, which focuses on domains that  
multiplex a sufficient numbers of flows such that stateless,  
statistical mechanisms are effective.

Explicit probing adds a lot of complexity. The idea behind PCN is to  
add a minimal set of mechanisms to a large and busy DiffServ domain,  
which would allow this domain to protect the QoS of already-admitted  
flows in a best-effort sort of way. Meaning that although flow  
termination should be mostly prevented due to admission stop  
decisions, there will be no guarantees that no flow will ever be  
terminated. PCN is also not a mechanism to squeeze the last ounce of  
utilization out of a domain - sufficient overprovisioning remains a  
requirement. Because of this, I wonder if PCN needs to support ECMP -  
which did not come up during the chartering phase - when it looks  
likely that such support will significantly complicate the solution.

Finally, let me say that I'm worried that the WG seems to have  
settled on a mode of working where all the different proposals will  
be merged into one. The result is not likely to be a very simple  
solution. We have ample experience with solutions that have been  
designed in this manner failing to gain any traction, due to their  
complexities.

I'd like to strongly encourage the WG to instead discuss which of the  
proposals is the most *simple* one that will fulfill the chartered  
goals. We'd like the outcome of the first phase of work to be  
something that people will usefully deploy in some domains. Without  
demonstrated deployability and use, the need for continued future  
work on PCN is questionable.

Lars

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 29 Sep 2007 09:19:34 +0000

Hi Steven

 Regarding the below comment:

> On 9/28/2007, "Steven Blake" <[email-masked]> wrote:

>PCN domain, and that no ICMP traffic can be sent back towards the

Georgios: You are right about the security implications, therefore a
requirement that has to hold is that the (end)node that initiates the
flow should maintain security associations with the PCN-ingress node
that initiates probing.

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 29 Sep 2007 09:22:27 +0000

Hi Lars

Agree with you regarding the comment on developing a solution that is not
too complex, but if this solution is too simple and is not able to solve
serius issues then this solution will not be deployed eather.

Best regards,
Georgios

---

From: Tina TSOU <[email-masked]>
Date: Sun, 30 Sep 2007 14:06:52 +0800

Hi,
Pls see comments in line demarked with [Tina: ...](:

B. R.
Tina

  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Saturday, September 29, 2007 1:30 AM
  Subject: RE: [PCN] PCN architecture, revised sub-section on probing

  Ruediger,

  [RG] - the discussion on the decision when to apply probing misses one important aspect, at least if 

    you look at a single domain: probing is only required if any pre-congestion occurs within this 

    domain. If there's no pre congested link within a domain, no probing is required within this 

    domain. 

  [phil] I slightly re-phrased the first bullet (the second bullet is unaltered), so the text now says:

     o  when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision), 

  [Tina: If the fact is the same above, if Probe message is sent, Ingress Node needs to send much more Probe Message traffic than the existing traffic. I think this will significantly increase the flow level in the domain.
  And will also take too much effort to generate these messages.]

  but the traffic levels on other ingress-egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate.  Probing is useful to check this.

  [Tina: I think Probe message is used to acquire the "pre-congestion" condition within the PCN domain. So Probe Message is only required when Ingress Node needs to make judgment to flow, but it has no knowledge about the condition within the domain. So Probing message is needed.
  The present PCN mechanism is designed as such that only Egress Node can know the flow forward status. This status must be sent to Ingess Node so as that Ingress Node can make Flow Admission or Flow Termination. Any circumstances that Ingress need to know the pre-congestion status within the domain, but Ingress Node doesn't know (such as ingress-egress-aggregate carries no traffic or too little traffic to accurately make measurement). It needs to send Probe message to acquire the pre-congestion status.]

     o  in the presence of multipath routing (ECMP) between the PCN-boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested.  Probing is useful to determine whether the new flow would follow a path that isn't pre-congested and hence can be admitted.

  [Tina: Probe message is not so intelligent to be routed to not-congestion path. So when forwarded, Probe message isn't necessary to flow across the one that is congested. Thus in this condition, Probe Message doesn't finish its mission.]

  I think what's written implies that it may not always be possible to know whether there's any (relevant) pre-congestion or none - so there's an argument for probing in such times of doubt to discover what the situation really is (if it turns out that there isn't any pre-congestion then, as you say, in some ways the probing hasn't proved to be useful). I think the tweaked text above captures this, but please suggest any mods to make it clearer (or disagree!)

  [RG} - given that probing is only applied within a domain, if there's pre-congestion on any link, then 

    the only purpose of probing is to find out, whether traffic from the particular ingress to a 

    desired egress would contribute to this pre-congestion. The probing flow then should be 

    designed to ensure that packets of the probing flow are marked (and if interpretation is 

    to be as simple as possible: marked probing packets mean no admission). 

  [phil] I'm not quite sure what you mean by "designed to ensure that packets of the probing flow are marked". The section currently says that probe pkts are handled in the same way as (ordinary data) PCN-pkts [*]. I think you may be suggesting something different, that probing pkts should be preferentially PCN-marked? 

  [*] incidentally, I'll tweak the text to add something like "in terms of pkt scheduling/forwarding and PCN-marking" ; for pkt dropping it may be arguable you should preferentially drop probes to ease DoS worries?

  Re: "interpretation is to be as simple as possible: marked probing packets mean no admission" - I think this is too solution-space for this Architecture draft (presumably there may be different options, eg block call if the single probe pkt is marked, if at least 2 out of 100 marked, etc)

  [RG] - If there's no flow between an ingress and an egress and ECMP is operational within a 

    domain, the ingress may have to signal its intention to probe to an egress.

  At the moment the doc says that "(if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed". But you're suggesting there are particular circumstances when something is needed in the opposite direction?

  Thanks!

  phil

------------------------------------------------------------------------------