Subject: [PCN] draft-ietf-pcn-architecture-03

From: Steven Blake <[email-masked]>
Date: Fri, 22 Feb 2008 15:29:10 +0000

The chairs would like input on whether the working group has read
draft-ietf-pcn-architecture-03, and believes that it is ready for
working group last call.  Please send your comments to this list.

Regards,

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

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

---

From: <[email-masked]>
Date: Fri, 22 Feb 2008 18:04:09 -0000

Not sure if I'm allowed to comment, since I edited it, but if I am then
I believe it's ready for WGLC!

Best wishes, 
Phil

Ps to save you having to read it all again!

* Diffs from -02 version 
http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn-
architecture-03-from-02.diff.html 

* a detailed list of changes is in S14.1 (there aren't many)
http://tools.ietf.org/html/draft-ietf-pcn-architecture-03#section-14.1 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Steven Blake
> Sent: 22 February 2008 15:29
> To: pcn
> Subject: [PCN] draft-ietf-pcn-architecture-03
>

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 17:12:20 -0000

I support this moving to working group last call in its current form

Toby
____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven Blake

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 26 Feb 2008 11:33:52 +0100

Hi Steven,

based on contents I agree that the architecture is in good shape and
can move to last call.

I'd expect comments from last call on formulations, not on content.
Examples:

- there's no figure explaining the functionalities and interfaces.
- the term "signaling" is used in different sections to refer to
  * indication of pre-congestion.
  * feedback of measured pre-congestion (or admission/termination).
  * transfer per flow information at boundary nodes.

The WG is well aware of the context when "signaling" pops up somewhere, 
but a new reader probably isn't and may loose track on some occasions. 
I'll comment details later.

Regards,

Rudiger

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Feb 2008 16:12:49 +0100

Hi Steven, Hi Phil

I have read the draft!
In my opinion it is ready for Working Group Last Call!

However, I have a comment regarding bullet 4 in Section 7.2:

  * Forward probe packets - as far as PCN-interior-nodes are
      concerned, probe packets "must be handled" the same as (ordinary
      data) PCN-packets, in terms of routing, scheduling and PCN-
      marking.

In the above text please change "must be handled" to "should be handled".
The reason of this request, is related to the fact that in some scenarios
the probe packet is used before a flow is admitted and therefore it can be 
handled differently than other data packets that are sent during the 
duration of a flow.

Best regards,
Georgios

> Sent: vrijdag 22 februari 2008 16:29
> To: pcn
> The chairs would like input on whether the working group has 
> read draft-ietf-pcn-architecture-03, and believes that it is 
> ready for working group last call.  Please send your comments 
> to this list.
> 
> 
> Regards,
>

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 15:34:39 -0000

> the probe packet is used before a flow is admitted 

yes, probe is sent before flow admitted

> and therefore it can be

'therefore...' - I don't understand how this follows.
I thought [1] probe pkts look the same as data pkts, how can the
interior node distinguish them? [2] if probe pkts weren't handled the
same way, then it would be dangerous for the egress to use the probe to
make an admission decision.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Feb 2008 16:51:18 +0100

Hi Phil

> I thought [1] probe pkts look the same as data pkts, how can 
> the interior node distinguish them?

Georgios: By using e.g., a Router Alert option, 
A RSVP PATH message carries a Router Alert option!
For more details see Section 3.1.2.1 and 4.2.1 in:
http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.txt

> [2] if probe pkts weren't 
> handled the same way, then it would be dangerous for the 
> egress to use the probe to make an admission decision.

Georgios: please see Section 3.1.2.2 and 4.2.2 in 
http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.txt

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: dinsdag 26 februari 2008 16:35
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
> 
> I thought [1] probe pkts look the same as data pkts, how can 
> the interior node distinguish them? [2] if probe pkts weren't 
> handled the same way, then it would be dangerous for the 
> egress to use the probe to make an admission decision.
> 
>

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 16:10:56 -0000

Georgios

I checked these sections. They say things like
"Thus if a PCN-
   interior-node receives a probe packet then, due to the Router Alert
   option it has to handle it differently then the user packets.  "

what I couldn't find is what " handle it differently" actually means
(and why the interior node is handling them differently)

thanks
phil

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 26 February 2008 15:51
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Cc: [email-masked]
http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.t
xt
> Georgios: please see Section 3.1.2.2 and 4.2.2 in
http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-03.t
xt

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Feb 2008 17:17:07 +0100

Hi Phil

In general, when a packet carries a Router Alert option, 
then it is handled differently than other packets. In particular,
it is taken out the fast forwarding path.

Now if the packet is a PCN aware packet, i.e., 
it is marked as a 
not congested PCN packet or 
PCN_marking or PCN_Affected_Marking encoded, 
and carries a Router Alert option, then the PCN-interior node 
will able to distinguish it from the other PCN aware packets.

Best regards,
Georgios

> Sent: dinsdag 26 februari 2008 17:11
> I checked these sections. They say things like "Thus if a PCN-
> what I couldn't find is what " handle it differently" 
> actually means (and why the interior node is handling them 
> differently)
> 
> thanks
> phil
> 
> > > interior node distinguish them?
> > 
> > Georgios: By using e.g., a Router Alert option, A RSVP PATH message 
> > carries a Router Alert option!
> egress to 
> > > use the probe to make an admission decision.
> > 
> > > interior node distinguish them? [2] if probe pkts weren't handled 
> > > the same way, then it would be dangerous for the egress 
> to use the 
> > > probe to make an admission decision.
> > >
> > >
> > 
>

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 16:45:24 -0000

But why would the interior node *need* to distinguish it from other pcn
pkts?

And even if you have got router alert, the architecture draft says:
"must be handled the same as (ordinary data) PCN-packets, in terms of
routing, scheduling and PCN-marking."
Even though your router alert's got it in slow path, will it handle it
any differently in terms of routing scehdulign & pcn-marking?

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Feb 2008 18:59:34 +0200

> working group last call.  Please send your comments to this list.

The document does a tremendous job of outlining the PCN architecture -  
nice job.

I don't think it is ready for WGLC yet, however. This is, because  
there are still several places where it simply lists options for doing  
things that are still under discussion, and for which the WG needs to  
come to consensus on *one* option. I'm not faulting the document or  
the authors; this is merely a reflection of the WG not having come to  
consensus yet.

Lars

Detailed comments:

Section 1., paragraph 9:
 >    o  The PCN-egress-nodes make separate measurements, operating on  
the
 >       aggregate PCN-traffic from each PCN-ingress-node, ie not per  
flow.
 >       Similarly, signalling by the PCN-egress-node of PCN-feedback-
 >       information (which is used for flow admission and termination
 >       decisions) is at the granularity of the ingress-egress- 
aggregate.
 >       An alternative approach is that the PCN-egress-nodes monitor  
the
 >       PCN-traffic and signal PCN-feedback-information (which is  
used for
 >       flow admission and termination decisions) at the granularity of
 >       one (or a few) PCN-marks.

   I don't understand what the "alternative approach" is doing - please
   elaborate.

Section 1., paragraph 19:

 >    o  Depending on the deployment scenario, the decision-making
 >       functionality (about flow admission and termination) could  
reside
 >       at the PCN-ingress-nodes or PCN-egress-nodes or (see  
Appendix) at
 >       some central control node in the PCN-domain.

   It is important to discuss somewhere that some choices here are less
   optimal than others. A good decision-making location is where PCN
   information naturally accumulates, e.g. at the egress. Any relocation
   of that decision-making requires additional communication, which
   increases the delay of the control loop and makes the system more
   brittle, because correct operation now requires dependable
   communication between the egress and the decision-making point. I'd
   like to suggest that we attempt to come to consensus on whether we  
can
   focus on a single decision point for PCN.

Section 1., paragraph 21:
 >    o  The PCN-domain extends to the end users.  The scenario is
 >       described in [I-D.babiarz-pcn-sip-cap].  A variant is that the
 >       PCN-domain extends out as far as the LAN edge switch.

   This deployment model may not be possible under the initial charter,
   or maybe even under an extended charter, because it is not clear that
   sufficient statistical multiplexing exists on the links near the edge
   to make PCN work, which is a *fundamental* assumption of PCN (see
   assumption 3 in Section 3). Listing this deployment scenario here  
when
   we aren't sure how to support it raises false expectations - I'd  
hence
   propose to drop this bullet item.

Section 1., paragraph 27:
 >    From the perspective of the outside world, a PCN-domain  
essentially
 >    looks like a DiffServ domain.  PCN-traffic is either transported
 >    across it transparently or policed at the PCN-ingress-node (ie
 >    dropped or carried at a lower QoS).  A couple of differences are
 >    that: PCN-traffic has better QoS guarantees than normal DiffServ
 >    traffic (because PCN's mechanisms better protect the QoS of  
admitted
 >    flows); and in rare circumstances (failures), on the one hand some
 >    PCN-flows may get terminated, but on the other hand other flows  
will
 >    get their QoS restored.  Non PCN-traffic is treated  
transparently, ie
 >    the PCN-domain is a normal DiffServ domain.

   This paragraph would make more sense earlier in the intro.

Section 3.5., paragraph 2:
 >    The following two assumptions apply if the PCN WG decides to  
encode
 >    PCN-marking in the ECN-field.

   Please add that any such encoding needs to conform to RFC4774.

Section 4.1., paragraph 4:
 >    NOTE: Two main categories of algorithm have been proposed: if the
 >    algorithm uses threshold-marking then all PCN-packets are marked  
if
 >    the current rate exceeds the PCN-lower-rate, whereas if the  
algorithm
 >    uses excess-rate-marking the amount marked is equal to the  
amount in
 >    excess of the PCN-lower-rate.  However, note that this description
 >    reflects the overall intent of the algorithm rather than its
 >    instantaneous behaviour, since the rate measured at a particular
 >    moment depends on the detailed algorithm, its implementation and  
the
 >    traffic's variance as well as its rate (eg marking may well  
continue
 >    after a recent overload even after the instantaneous rate has
 >    dropped).

   It seems important that we come to consensus on which scheme will be
   used for PCN before we move forward with the architecture. Otherwise,
   we're merely postponing a difficult decision we'll have to tackle
   eventually anyway.

Section 4.1., paragraph 7:
 >    o  if the PCN-egress-node receives one (or several) PCN-marked
 >       packets, then a new flow is blocked, otherwise it is admitted.

   I don't understand this - please elaborate. (Is this related to my
   earlier comment about the "alternative approach"?)

Section 4.2., paragraph 1:
 >    At a high level, flow termination control works as follows.  Each
 >    PCN-node PCN-marks packets in a similar fashion to above, with all
 >    proposals using an excess-rate-marking approach (Section 4.1).  An
 >    obvious approach is for the algorithm to use a second configured
 >    parameter, PCN-upper-rate, and a second header encoding.  However
 >    there is also a proposal to use the same rate and the same  
encoding.

   Are we coming to consensus on which to pick moving forward? As  
before,
   I'd like us to avoid postponing difficult decisions.

Section 4.3., paragraph 4:
 >    A different possibility is to configure only the PCN-lower-rate  
and
 >    hence only do one type of PCN-marking, but generate admission and
 >    flow termination responses from different levels of marking.   
This is
 >    suggested in [I-D.charny-pcn-single-marking] which gives some of  
the
 >    pros and cons of this approach.

   draft-charny is at odds with the second paragraph of the intro, which
   says that each link has a PCN-lower-rate and a PCN-upper-rate. If the
   intent of the architecture is to permit a proposal like draft-charny,
   those concepts need to be re-defined.

Section 4.5., paragraph 2:
 >    o  There needs to be a way for a PCN-node to distinguish PCN- 
traffic
 >       from non PCN-traffic.  They may be distinguished using the DSCP
 >       field and/or ECN field.

   Please refer to RFC4774 again.

Section 5.3., paragraph 5:
 >    Another PCN WG document, about boundary mechanisms, will describe
 >    PCN-metering in more detail.  As described in Section 4.1 and  
Section
 >    4.2, at present there are two alternative proposals: to measure  
as an
 >    aggregate (ie not per flow) all PCN-packets from a particular PCN-
 >    ingress-node; or to monitor the PCN-traffic and react to one (or
 >    several) PCN-marks.  We refer to these approaches as "measuring  
PCN-
 >    traffic" and "monitoring PCN-marks".  The PCN-metering  
functionality
 >    also depends on whether the measurement is targeted at admission
 >    control or flow termination.  It also depends on what encoding and
 >    PCN-marking algorithms are specified by the PCN WG.

   OK, this clarifies the "alternative approach that I had two comments
   about above a bit more. I'd suggest to move some of that explanation
   earlier in the document. (But we do need to decide on which option to
   go with, too.)

Section 5.4., paragraph 8:
 >    The decision needs to be passed to the application layer so that  
it
 >    can take the appropriate action.

   The application layer at what node? And define "appropriate".

Section 5.6., paragraph 4:
 >    o  Use a probe packet that includes as payload the address of the
 >       PCN-ingress-node.

   I don't understand how a probe packet can be used by the egress to
   determine the address of the ingress, if the egress needs to know  
this
   address to send the probe packet. (But see my comment on probing  
below;
   this may be moot.)

Section 5.8., paragraph 0:
 > 5.8.  Fault handling

   It may be a good idea to add a paragraph that describes that
   re-routing must be constrained in a way that upholds the boundary of
   the PCN domain. In other words, re-routing MUST NOT cause traffic to
   enter the domain without going through a PCN ingress.

Section 7., paragraph 0:
 > 7.  Probing

   I am still opposed to probing as part of the PCN architecture. It  
is a
   *very* complex mechanism with lots of open issues surrounding how it
   could actually be implemenented that in the end serves only one
   purpose: to slightly increase capacity utilization in a PCN domain.
   However, PCN was never meant to remove the need for sufficient
   overprovisioning. A second reason is that probing is only really
   needed to extend PCN into scenarios where some of the assumptions
   (sufficient multiplexing, etc.) are no longer true. We already have a
   boatload of explicitly-signalled QoS architectures that were designed
   for just such scenarios. I see no reason to complicate PCN into yet
   another signalled-QoS system.

   We already had consensus in Vancouver to stop discussing probing  
until
   after work on the initial milestones has finished. I'd like to  
propose
   to remove the discussion of probing from the architecture at least  
until
   that time.

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

NITS (only of interest to the authors)

   Nit: eliminate use of first person (throughout the document)
   Nit: s/ie/i.e.,/ (everywhere)
   Nit: s/eg/e.g.,/ (everywhere)

Section 2., paragraph 1:
 >       nodes that perform DiffServ scheduling; the compete set of PCN-

   Nit: s/compete/complete/

Section 4.3., paragraph 2:
 >    sessions end, existing microflows naturally depart from the system

   Nit: s/microflow/flow/ (or else define what a microflow is; also
                           elsewhere in the document)

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Feb 2008 18:05:43 +0100

Hi Phil

* Regarding Routing NOT, 
* Regarding scheduling, NOT
* Regarding PCN_marking, it could be handled differently:

  ** if excess rate marking is used AND the PCN-interior-node is congested
AND 
     the probe packet contains the ROUTER ALERT option THEN
     the probe packet can be distinguished from the other PCN packets,
     and therefore it will be for sure PCN_marking encoded.

  ** if excess rate marking is used AND the PCN-interior-node is congested
AND 
     the probe packet DOES NOT contain the ROUTER ALERT option 
     THEN this MIGHT be PCN_marking encoded, or it MIGHT not be PCN_marking
encoded. This depends
     on whether this probe packet is selected to represent the excess rate,
or is not selected.

Best regards,
Georgios

> Sent: dinsdag 26 februari 2008 17:45
> But why would the interior node *need* to distinguish it from 
> other pcn pkts?
> 
> "must be handled the same as (ordinary data) PCN-packets, in 
> terms of routing, scheduling and PCN-marking."
> Even though your router alert's got it in slow path, will it 
> handle it any differently in terms of routing scehdulign & 
> pcn-marking?
> 
>

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 17:16:15 -0000

Sorry, to repeat:

I still have not the foggiest idea why on earth someone would want or
need or be interested in the interior node handling probe pkts
differently from the way it handles probe pkts.

So far you have answered a different question, about whether it would be
possible for someone to devise pcn so that an interior node could
distinguish probe pkts from data pkts. As you say, a router alert option
could indeed be used. 

> Sent: 26 February 2008 17:06

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 27 Feb 2008 09:41:26 +0100

Phil, Georgios,

wasn't there a decision in Vancouver to stop work on probing and 
leave the description in the architecture document as it is? 

Regards,

Rudiger 

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] 
| Sent: Tuesday, February 26, 2008 6:16 PM
| To: [email-masked]; [email-masked]
| Cc: [email-masked]
| Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| 
| Sorry, to repeat:
| 
| I still have not the foggiest idea why on earth someone would 
| want or need or be interested in the interior node handling 
| probe pkts differently from the way it handles probe pkts.
| 
| So far you have answered a different question, about whether 
| it would be possible for someone to devise pcn so that an 
| interior node could distinguish probe pkts from data pkts. As 
| you say, a router alert option could indeed be used. 
| 
| > -----Original Message-----
| > From: Georgios Karagiannis [mailto:[email-masked]]
| > Sent: 26 February 2008 17:06
| > To: Eardley,PL,Philip,CXR9 R; [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > 
| > Hi Phil
| > 
| > * Regarding Routing NOT,
| > * Regarding scheduling, NOT
| > * Regarding PCN_marking, it could be handled differently:
| > 
| >   ** if excess rate marking is used AND the PCN-interior-node is
| congested
| > AND
| >      the probe packet contains the ROUTER ALERT option THEN
| >      the probe packet can be distinguished from the other 
| PCN packets,
| >      and therefore it will be for sure PCN_marking encoded.
| > 
| >   ** if excess rate marking is used AND the PCN-interior-node is
| congested
| > AND
| >      the probe packet DOES NOT contain the ROUTER ALERT option
| >      THEN this MIGHT be PCN_marking encoded, or it MIGHT not be 
| > PCN_marking encoded. This depends
| >      on whether this probe packet is selected to represent 
| the excess 
| > rate, or is not selected.
| > 
| > Best regards,
| > Georgios
| > 
| > 
| > 
| > 
| > 
| > > -----Original Message-----
| > > From: [email-masked] [mailto:[email-masked]]
| > > Sent: dinsdag 26 februari 2008 17:45
| > > To: [email-masked]; [email-masked]
| > > Cc: [email-masked]
| > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > >
| > > But why would the interior node *need* to distinguish it 
| from other 
| > > pcn pkts?
| > >
| > > And even if you have got router alert, the architecture 
| draft says:
| > > "must be handled the same as (ordinary data) PCN-packets, 
| in terms 
| > > of routing, scheduling and PCN-marking."
| > > Even though your router alert's got it in slow path, will 
| it handle 
| > > it any differently in terms of routing scehdulign & pcn-marking?
| > >
| > >
| > 
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| http://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 10:49:54 -0000

Lars,
Thanks for the detailed pointers on what we need to come to consensus
on. And the other detailed comments.
Thanks for the follow-up Rudiger.

Summary:-

1. I think we have consensus on the admission marking behaviour, I'll
send a separate email on this shortly.

2. I think we have consensus on the termination marking behaviour, I'll
send a separate email on this shortly. Assuming that Joe is convinced by
Michael's EMFT i-d.

3. in terms of edge behaviour for admission & termination, do we need
consensus on one solution? Since the Charter I thought that the approach
was that edge behaviour is in Info docs and that there could be more
than one edge behaviour (but a single Std for interior behaviour). 
Anyway, there are two approaches suggested for admission (level of
congestion & probing) and two for termination (measuring rates and
termination based on flow being marked). I don't know how to reach
consensus on doing one of each - perhaps we could have consensus on
which to do first??? 

4. in terms of where the decision making functionality resides, the
ingress is probably more natural - since it polices flows and
understands any other flow requirements that might impact the decision
(such as relative importance). As to what is signalled, I guess that
partly depends on what approach is being taken in point 3. 
the centralised node is also possible for decision making, but it's
clearly understood that this is out of scope.

5. you asked about single marking. I don't know if we have consensus. My
view is that the single marking approach isn't accurate enough for
admission control, except perhaps as a migration step. allowing this
possibility would require a bit more complexity in the edge behaviour
Info doc (extra parameter configured same for all boundary nodes, tweak
to termination behaviour at edges).

A few follow-ups below (the rest I'll just work in).

Thanks
phil

Lars
> Eggert
> Sent: 26 February 2008 17:00
> To: ext Steven Blake
> Cc: pcn
> Subject: Re: [PCN] draft-ietf-pcn-architecture-03
> 
> 

Yes, it assumes that the links near the edge have sufficient stat
multiplexing. I'll move it to the Appendix, with a note that if there is
sufficient stat multiplexing then it's in scope. 

>    those concepts need to be re-defined.

I'll try & clarify this. 
I think S4.3. (Flow admission and flow termination) needs to be
clarified, and to clarify in Intro that PCN-domain doesn't have to do
admission & termination, but could just do one of them. 

>    The application layer at what node? And define "appropriate".

I think this sentence can be deleted, as it's already covered by the
earlier para in S5.4: "  o  Communicate decision about admission "

>    address to send the probe packet. (But see my comment on probing

"if the egress..."
not sure I understand, it's the ingress that sends the probe pkt. The
idea was that when the ingress sends the probe, it inserts into the pkt
its address (ie the ingress address) - which the egress then extracts
when it gets the probe. 

>    to remove the discussion of probing from the architecture at least

I can move the Probing section to an Appendix. Of course I could also
delete it, although I guess there'll be objections to that.

they can be spelt with or without the dots. I read somewhere that
without dots is the modern usage & have been a convert ever since!

>                            elsewhere in the document)

thanks, I managed to miss some. They mostly should be flow. Where it
means microflow I added ref to RFC2475 (eg in the PCN-traffic definition
in S2)

---

From: Michael Menth <[email-masked]>
Date: Wed, 27 Feb 2008 13:56:59 +0100

Hi,

> consensus on doing one of each - perhaps we could have consensus on
I think consensus is that probe based AC methods (PBAC) has lower 
priority than AC methods for ingress-egress aggregates. But even there 
we have two candidates: congestion level estimate based AC (CLEBAC, CL, 
3sm) and observation based AC (OBAC, 3sm). The following document 
compares these methods:
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-AC.pdf

> (such as relative importance). 
The ingress node is just the right place to enforce the decision.

Concerning admission control (AC),  it is rather simple to implement 
different AC decision algorithms at the egress when the egress node only 
signals decisions like "admission-stop" or "admission-continue" to the 
ingress node and the ingress node acts accordingly.

Concerning flow termination (FT), this is different. With indirect 
measured rate termination (IMRT, CL, SM, see also Section 3 of
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth07-PCN-Eval.pdf 
)
only the ingress node can take decisions. With direct MRT (DMRT), either 
the ingress or the egress node can take the FT decision without a lot of 
signalling across the PCN domain. With edge-assisted marked flow 
termination (EMFT), only the egress node can efficiently take FT 
decisions. Thus, the question of the decision making location depends on 
the exact algorithm when we want to avoid that many parameters are 
signalled across the PCN domain.

> As to what is signalled, I guess that
I agree.

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: Thu, 28 Feb 2008 11:19:42 +0100

Hi Phil

Sorry for not being clear!

As you know if ECMP routing is used then 
this might cause problems on the way of how
admission control and flow termination algorithms are operating.

The ECMP problem is related to the fact that flows can belong to a 
certain ingress-egress-aggregate, which is maintained at the ingress adn
egress 
and that operates in admission control state or flow termination state, but
that 
due to the ECMP routing they are not passing through the congested node.

Any measures that are taken on such flows will not solve the
congestion problem, since such flows are not contributing and causing
the congestion in the PCN-interior-node. 

Now when probing is used this problem can be solved as follows.
When a PCN-interior-node is congested it MUST PCN_marking encode a probe
packet.

Thus if an egress operates, for a certain ingress-egress-agrregate in
admission control 
state and it receives a probe packet which belongs to a flow associated with
the same
 ingress-egress-agrregate AND the probe packet is PCN_marking encoded, then
the 
egress knows for sure that the probe packet passed through one or 
more congested PCN-interior-nodes. In this case the probe packet, and thus
also the requiesting flow
can be rejected.

If an egress operates, for a certain ingress-egress-agrregate in admission
control 
state and it receives a probe packet which belongs to a flow associated with
the same
 ingress-egress-agrregate AND the probe packet is marked as not congested
PCN, then the 
egress knows for sure that the probe packet HAS NOT PASSED through a
congested PCN-interior-node 
due to e.g., used ECMP routing. In this case the probe packet can be
accepted, since this flow,
even it belongs to the ingress-egress-aggergate that operates in admission
control, is
not contributing and causing the congestion in the PCN-interior-node. 

Okay, but why one should provide the possibility to PCN-interior-nodes to 
distinguish between probe packets and other PCN aware user packets?

This is related to which admission control and flow termination 
algorithms and encodings are used in the PCN-interior-nodes.

If an algorithm uses one encoding state for admission control and another
encoding state 
for flow termination then probably it is not required to 
provide the possibility to PC_interior-node to distinguish between probe 
packets and PCN aware user packets.
This is because when the PCN-interior-node that operates in admission
control state 
will AM (admission control encoding state) 
encode all packets, i.e., probe packets and user packets.

If an algorithm uses only one encoding state for admission control and 
flow termionation, such as the ones used in the single marking (SM) and
LC-PCN drafts,
 then the PCN-interior-node msut be able to distinguish between probe
packets and user data packets.

This is because both algorithms SM and LC-PCN are encoding packets
proportionaly to the excess rate.
This means that when the PCN-interior-node opetrates in admission control
state it will not SM mark 
all packets that are passing through the node, but only a proportion that is
needed to 
represent the excess rate. Thus if the PCN-interior-node will not
distinguish between the probe packets and other PCN aware 
packets, then it is not certain that the probe packet will be SM marked when
the PCN-interior-node operates 
in admission control state.
Now, if the probe packets carry a Router Alert option, and when in Admission
control state,
the PCN-interior-node marks all packets that are carrying a Router Alert
option, then the probe packet will 
be for sure marked.

Hope that this clarifies your question!

Best regards,
Georgios

> Sent: dinsdag 26 februari 2008 18:16
> I still have not the foggiest idea why on earth someone would 
> want or need or be interested in the interior node handling 
> probe pkts differently from the way it handles probe pkts.
> 
> So far you have answered a different question, about whether 
> it would be possible for someone to devise pcn so that an 
> interior node could distinguish probe pkts from data pkts. As 
> you say, a router alert option could indeed be used. 
> 
> >      THEN this MIGHT be PCN_marking encoded, or it MIGHT not be 
> > PCN_marking encoded. This depends
> >      on whether this probe packet is selected to represent 
> the excess 
> > rate, or is not selected.
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> > 
> > 
> > > But why would the interior node *need* to distinguish it 
> from other 
> > > pcn pkts?
> > >
> > > "must be handled the same as (ordinary data) PCN-packets, 
> in terms 
> > > of routing, scheduling and PCN-marking."
> > > Even though your router alert's got it in slow path, will 
> it handle 
> > > it any differently in terms of routing scehdulign & pcn-marking?
> > >
> > >
> > 
>

---

From: Michael Menth <[email-masked]>
Date: Thu, 28 Feb 2008 11:28:15 +0100

Hi Georgios,

is it that you want to use excess rate marking for admission control, 
i.e. only some of the packets are marked, but at the same time you want 
to guarantee that all probe packets are marked? You realize that by 
simple excess rate marking of data packets and by using a router alert 
option for probe packets to make sure that PCN nodes always mark them 
when corresponding links are pre-congested with regard to the admissible 
rate?

Regards,

    Michael

Georgios Karagiannis wrote:
>>>   ** if excess rate marking is used AND the PCN-interior-node is
>>>       
>> congested
>>     
>>> AND
>>>      the probe packet can be distinguished from the other 
>>>       
>> PCN packets,
>>     
>>>   ** if excess rate marking is used AND the PCN-interior-node is
>>>       
>> congested
>>     
>>> AND
>>>> And even if you have got router alert, the architecture 
>>>>         
>> draft says:
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 11:30:56 +0100

Hi Michael

Yes to all your questions!

Best regards,
Georgios

> From: Michael Menth [mailto:[email-masked]] 
> Sent: donderdag 28 februari 2008 11:28
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> is it that you want to use excess rate marking for admission 
> control, i.e. only some of the packets are marked, but at the 
> same time you want to guarantee that all probe packets are 
> marked? You realize that by simple excess rate marking of 
> data packets and by using a router alert option for probe 
> packets to make sure that PCN nodes always mark them when 
> corresponding links are pre-congested with regard to the 
> admissible rate?
> 
> Regards,
> 
>     Michael
> 
> > As you know if ECMP routing is used then this might cause 
> problems on 
> > the way of how admission control and flow termination 
> algorithms are 
> > operating.
> >
> > certain ingress-egress-aggregate, which is maintained at 
> the ingress 
> > adn egress and that operates in admission control state or flow 
> > termination state, but that due to the ECMP routing they are not 
> > passing through the congested node.
> >
> > When a PCN-interior-node is congested it MUST PCN_marking encode a 
> > probe packet.
> >
> >
> > admission control state and it receives a probe packet 
> which belongs 
> > to a flow associated with the same  
> ingress-egress-agrregate AND the 
> > probe packet is PCN_marking encoded, then the egress knows for sure 
> > that the probe packet passed through one or more congested 
> > PCN-interior-nodes. In this case the probe packet, and thus 
> also the 
> > requiesting flow can be rejected.
> >
> > If an egress operates, for a certain ingress-egress-agrregate in 
> > admission control state and it receives a probe packet 
> which belongs 
> > to a flow associated with the same  
> ingress-egress-agrregate AND the 
> > probe packet is marked as not congested PCN, then the 
> egress knows for 
> > sure that the probe packet HAS NOT PASSED through a congested 
> > PCN-interior-node due to e.g., used ECMP routing. In this case the 
> > probe packet can be accepted, since this flow, even it 
> belongs to the 
> > ingress-egress-aggergate that operates in admission control, is not 
> > contributing and causing the congestion in the PCN-interior-node.
> >
> >
> > Okay, but why one should provide the possibility to 
> PCN-interior-nodes 
> > to distinguish between probe packets and other PCN aware 
> user packets?
> >
> > If an algorithm uses one encoding state for admission control and 
> > another encoding state for flow termination then probably it is not 
> > required to provide the possibility to PC_interior-node to 
> distinguish 
> > between probe packets and PCN aware user packets.
> > control state will AM (admission control encoding state) encode all 
> > packets, i.e., probe packets and user packets.
> >
> > flow termionation, such as the ones used in the single marking (SM) 
> > and LC-PCN drafts,  then the PCN-interior-node msut be able to 
> > distinguish between probe packets and user data packets.
> >
> > This means that when the PCN-interior-node opetrates in admission 
> > control state it will not SM mark all packets that are 
> passing through 
> > the node, but only a proportion that is needed to represent 
> the excess 
> > rate. Thus if the PCN-interior-node will not distinguish 
> between the 
> > probe packets and other PCN aware packets, then it is not 
> certain that 
> > the probe packet will be SM marked when the 
> PCN-interior-node operates 
> > Now, if the probe packets carry a Router Alert option, and when in 
> > Admission control state, the PCN-interior-node marks all 
> packets that 
> > are carrying a Router Alert option, then the probe packet 
> will be for 
> > sure marked.
> >
> >> So far you have answered a different question, about 
> whether it would 
> >> be possible for someone to devise pcn so that an interior 
> node could 
> >> distinguish probe pkts from data pkts. As you say, a router alert 
> >> option could indeed be used.
> >>
> >>     
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 Feb 2008 12:44:35 +0200

Hi,

I'm not sure if I have fully digested this yet, but it seems like this  
proposal defines different semantics for what the PCN marks mean to  
both the interior and egress nodes, depending on whether a packet is a  
probe packet or not. That seems to add significant complexity.

Lars

On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote:

> probe
> admission
> another
> Admission

---

From: Michael Menth <[email-masked]>
Date: Thu, 28 Feb 2008 11:49:32 +0100

Hi Lars,

I just want to point out that this complexity is not due to probing 
itself but due to the use of excess rate marking for admission control. 
There is no such increased complexity if probing is done in combination 
with exhaustive (threshold) marking for admission control.

Regards,

    Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 11:57:44 +0100

Hi Lars

Even for excess rate marking the complexity added is not signifficant.
The Router Alert processing is already available in each router.
The only additional complexity is related to the fact that the 
PCN-interior-node will PCN_marking encode the packets that are 
carrying a Router Alert option. 

Best regards,
Georgios

> Behalf Of Michael Menth
> Sent: donderdag 28 februari 2008 11:50
> To: Lars Eggert
> Cc: pcn
> I just want to point out that this complexity is not due to 
> probing itself but due to the use of excess rate marking for 
> admission control. 
> There is no such increased complexity if probing is done in 
> combination with exhaustive (threshold) marking for admission control.
> 
> Regards,
> 
>     Michael
> 
> Lars Eggert wrote:
> > Hi,
> >
> >> PCN-interior-nodes. In this case the probe packet, and 
> thus also the 
> >> probe packet is marked as not congested PCN, then the egress knows 
> >> for sure that the probe packet HAS NOT PASSED through a congested 
> >> Okay, but why one should provide the possibility to PCN-interior- 
> >> nodes to distinguish between probe packets and other PCN 
> aware user 
> >> packets?
> >>
> >> distinguish between probe packets and PCN aware user packets.
> >> If an algorithm uses only one encoding state for admission control 
> >> and flow termionation, such as the ones used in the single marking 
> >> (SM) and LC-PCN drafts, then the PCN-interior-node msut be able to 
> >> control state it will not SM mark all packets that are passing 
> >> through the node, but only a proportion that is needed to 
> represent 
> >> the excess rate. Thus if the PCN-interior-node will not 
> distinguish 
> >> between the probe packets and other PCN aware packets, 
> then it is not 
> >> certain that the probe packet will be SM marked when the 
> >> PCN-interior-node operates in admission control state.
> >>> I still have not the foggiest idea why on earth someone 
> would want 
> >>> or need or be interested in the interior node handling probe pkts 
> >>> So far you have answered a different question, about whether it 
> >>> would be possible for someone to devise pcn so that an 
> interior node 
> >>> could distinguish probe pkts from data pkts. As you say, a router 
> >>> alert option could indeed be used.
> >>>
> >>>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 28 Feb 2008 12:27:23 +0100

Hi Georgios,

| Even for excess rate marking the complexity added is not signifficant.
| The Router Alert processing is already available in each router.
| The only additional complexity is related to the fact that 
| the PCN-interior-node will PCN_marking encode the packets 
| that are carrying a Router Alert option. 

I understand your goal and your idea. I can't recall DiffServ to be 
a mechanism requiring RAO treatment from any router within a 
DiffServ domain. As PCN is a DiffServ based mechanism and I'm quite 
happy with the idea not to depend on RAO evaluation. I look at the 
feature you propose as a possible option.

My companies network is operating with DiffServ and is using 
MPLS and ECMP. I'd like PCN to be standardised in a way not demanding 
complex software for the backbone routers (like RAO for MPLS - which 
you did not propose, but we also shouldn't end there). Preferably, 
per flow treatment intelligence should reside in edge boxes (and 
only there).

Regards,

Rudiger

| Best regards,
| Georgios
| 
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of 
| > Michael Menth
| > Sent: donderdag 28 februari 2008 11:50
| > To: Lars Eggert
| > Cc: pcn
| > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > 
| > Hi Lars,
| > 
| > I just want to point out that this complexity is not due to probing 
| > itself but due to the use of excess rate marking for admission 
| > control.
| > There is no such increased complexity if probing is done in 
| > combination with exhaustive (threshold) marking for 
| admission control.
| > 
| > Regards,
| > 
| >     Michael
| > 
| > Lars Eggert wrote:
| > > Hi,
| > >
| > > I'm not sure if I have fully digested this yet, but it
| > seems like this
| > > proposal defines different semantics for what the PCN 
| marks mean to 
| > > both the interior and egress nodes, depending on whether a
| > packet is a
| > > probe packet or not. That seems to add significant complexity.
| > >
| > > Lars
| > >
| > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote:
| > >
| > >   
| > >> Hi Phil
| > >>
| > >> Sorry for not being clear!
| > >>
| > >> As you know if ECMP routing is used then this might cause
| > problems on
| > >> the way of how admission control and flow termination
| > algorithms are
| > >> operating.
| > >>
| > >> The ECMP problem is related to the fact that flows can 
| belong to a 
| > >> certain ingress-egress-aggregate, which is maintained at
| > the ingress
| > >> adn egress and that operates in admission control state or flow 
| > >> termination state, but that due to the ECMP routing they are not 
| > >> passing through the congested node.
| > >>
| > >> Any measures that are taken on such flows will not solve the 
| > >> congestion problem, since such flows are not contributing
| > and causing
| > >> the congestion in the PCN-interior-node.
| > >>
| > >> Now when probing is used this problem can be solved as follows.
| > >> When a PCN-interior-node is congested it MUST 
| PCN_marking encode a 
| > >> probe packet.
| > >>
| > >>
| > >> Thus if an egress operates, for a certain
| > ingress-egress-agrregate in
| > >> admission control state and it receives a probe packet
| > which belongs
| > >> to a flow associated with the same
| > ingress-egress-agrregate AND the
| > >> probe packet is PCN_marking encoded, then the egress knows
| > for sure
| > >> that the probe packet passed through one or more congested 
| > >> PCN-interior-nodes. In this case the probe packet, and
| > thus also the
| > >> requiesting flow can be rejected.
| > >>
| > >> If an egress operates, for a certain ingress-egress-agrregate in 
| > >> admission control state and it receives a probe packet
| > which belongs
| > >> to a flow associated with the same
| > ingress-egress-agrregate AND the
| > >> probe packet is marked as not congested PCN, then the 
| egress knows 
| > >> for sure that the probe packet HAS NOT PASSED through a 
| congested 
| > >> PCN-interior-node due to e.g., used ECMP routing. In 
| this case the 
| > >> probe packet can be accepted, since this flow, even it
| > belongs to the
| > >> ingress-egress-aggergate that operates in admission
| > control, is not
| > >> contributing and causing the congestion in the PCN-interior-node.
| > >>
| > >>
| > >> Okay, but why one should provide the possibility to 
| PCN-interior- 
| > >> nodes to distinguish between probe packets and other PCN
| > aware user
| > >> packets?
| > >>
| > >> This is related to which admission control and flow termination 
| > >> algorithms and encodings are used in the PCN-interior-nodes.
| > >>
| > >> If an algorithm uses one encoding state for admission 
| control and 
| > >> another encoding state for flow termination then probably
| > it is not
| > >> required to provide the possibility to PC_interior-node to 
| > >> distinguish between probe packets and PCN aware user packets.
| > >> This is because when the PCN-interior-node that operates
| > in admission
| > >> control state will AM (admission control encoding state)
| > encode all
| > >> packets, i.e., probe packets and user packets.
| > >>
| > >> If an algorithm uses only one encoding state for 
| admission control 
| > >> and flow termionation, such as the ones used in the 
| single marking
| > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut 
| be able to 
| > >> distinguish between probe packets and user data packets.
| > >>
| > >> This is because both algorithms SM and LC-PCN are 
| encoding packets 
| > >> proportionaly to the excess rate.
| > >> This means that when the PCN-interior-node opetrates in 
| admission 
| > >> control state it will not SM mark all packets that are passing 
| > >> through the node, but only a proportion that is needed to
| > represent
| > >> the excess rate. Thus if the PCN-interior-node will not
| > distinguish
| > >> between the probe packets and other PCN aware packets,
| > then it is not
| > >> certain that the probe packet will be SM marked when the 
| > >> PCN-interior-node operates in admission control state.
| > >> Now, if the probe packets carry a Router Alert option, 
| and when in 
| > >> Admission control state, the PCN-interior-node marks all
| > packets that
| > >> are carrying a Router Alert option, then the probe packet
| > will be for
| > >> sure marked.
| > >>
| > >> Hope that this clarifies your question!
| > >>
| > >> Best regards,
| > >> Georgios
| > >>
| > >>
| > >>
| > >>
| > >>
| > >>
| > >>     
| > >>> -----Original Message-----
| > >>> From: [email-masked] [mailto:[email-masked]]
| > >>> Sent: dinsdag 26 februari 2008 18:16
| > >>> To: [email-masked]; [email-masked]
| > >>> Cc: [email-masked]
| > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > >>>
| > >>> Sorry, to repeat:
| > >>>
| > >>> I still have not the foggiest idea why on earth someone
| > would want
| > >>> or need or be interested in the interior node handling 
| probe pkts 
| > >>> differently from the way it handles probe pkts.
| > >>>
| > >>> So far you have answered a different question, about whether it 
| > >>> would be possible for someone to devise pcn so that an
| > interior node
| > >>> could distinguish probe pkts from data pkts. As you 
| say, a router 
| > >>> alert option could indeed be used.
| > >>>
| > >>>       
| > >>>> -----Original Message-----
| > >>>> From: Georgios Karagiannis [mailto:[email-masked]]
| > >>>> Sent: 26 February 2008 17:06
| > >>>> To: Eardley,PL,Philip,CXR9 R; [email-masked]
| > >>>> Cc: [email-masked]
| > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > >>>>
| > >>>> Hi Phil
| > >>>>
| > >>>> * Regarding Routing NOT,
| > >>>> * Regarding scheduling, NOT
| > >>>> * Regarding PCN_marking, it could be handled differently:
| > >>>>
| > >>>>  ** if excess rate marking is used AND the PCN-interior-node is
| > >>>>         
| > >>> congested
| > >>>       
| > >>>> AND
| > >>>>     the probe packet contains the ROUTER ALERT option THEN
| > >>>>     the probe packet can be distinguished from the other
| > >>>>         
| > >>> PCN packets,
| > >>>       
| > >>>>     and therefore it will be for sure PCN_marking encoded.
| > >>>>
| > >>>>  ** if excess rate marking is used AND the PCN-interior-node is
| > >>>>         
| > >>> congested
| > >>>       
| > >>>> AND
| > >>>>     the probe packet DOES NOT contain the ROUTER ALERT option
| > >>>>     THEN this MIGHT be PCN_marking encoded, or it MIGHT not be 
| > >>>> PCN_marking encoded. This depends
| > >>>>     on whether this probe packet is selected to represent
| > >>>>         
| > >>> the excess
| > >>>       
| > >>>> rate, or is not selected.
| > >>>>
| > >>>> Best regards,
| > >>>> Georgios
| > >>>>
| > >>>>
| > >>>>
| > >>>>
| > >>>>
| > >>>>         
| > >>>>> -----Original Message-----
| > >>>>> From: [email-masked] [mailto:[email-masked]]
| > >>>>> Sent: dinsdag 26 februari 2008 17:45
| > >>>>> To: [email-masked]; [email-masked]
| > >>>>> Cc: [email-masked]
| > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > >>>>>
| > >>>>> But why would the interior node *need* to distinguish it
| > >>>>>           
| > >>> from other
| > >>>       
| > >>>>> pcn pkts?
| > >>>>>
| > >>>>> And even if you have got router alert, the architecture
| > >>>>>           
| > >>> draft says:
| > >>>       
| > >>>>> "must be handled the same as (ordinary data) PCN-packets,
| > >>>>>           
| > >>> in terms
| > >>>       
| > >>>>> of routing, scheduling and PCN-marking."
| > >>>>> Even though your router alert's got it in slow path, will
| > >>>>>           
| > >>> it handle
| > >>>       
| > >>>>> it any differently in terms of routing scehdulign & 
| pcn-marking?
| > >>>>>
| > >>>>>
| > >>>>>           
| > >> _______________________________________________
| > >> PCN mailing list
| > >> [email-masked]
| > >> https://www.ietf.org/mailman/listinfo/pcn
| > >>     
| > >
| > > _______________________________________________
| > > PCN mailing list
| > > [email-masked]
| > > https://www.ietf.org/mailman/listinfo/pcn
| > >   
| > 
| > --
| > 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://www.ietf.org/mailman/listinfo/pcn
| > 
| 
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 12:35:26 +0100

Hi Ruediger

I see the proposed probing feature as optional that can be used to solve the

ECMP routing problem that occurs during admission control.

But regarding your comment reagrding the per flow treatment, when using the
Router Alert option
the PCN-interior-node does not need to maintain any flow related
information.
If a PCN-interior-node operates in admission control state then
all packets that carry a Router Alert option, e.g., RSVP PATH, will
be PCN_marking encoded. In order to do this the PCN-interior-node 
 does not need to maintain any flow related information.

Bst regards,
Georgios

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: donderdag 28 februari 2008 12:27
> To: [email-masked]
> Cc: [email-masked]
> | The only additional complexity is related to the fact that the 
> | PCN-interior-node will PCN_marking encode the packets that are 
> | carrying a Router Alert option.
> 
> I understand your goal and your idea. I can't recall DiffServ 
> to be a mechanism requiring RAO treatment from any router 
> within a DiffServ domain. As PCN is a DiffServ based 
> mechanism and I'm quite happy with the idea not to depend on 
> RAO evaluation. I look at the feature you propose as a 
> possible option.
> 
> MPLS and ECMP. I'd like PCN to be standardised in a way not 
> demanding complex software for the backbone routers (like RAO 
> for MPLS - which you did not propose, but we also shouldn't 
> end there). Preferably, per flow treatment intelligence 
> should reside in edge boxes (and only there).
> 
> Regards,
> 
> Rudiger
> 
>  
> | Best regards,
> | Georgios
> | 
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 28 Feb 2008 12:43:59 +0100

Hi Georgios,

sure, the routers aren't required to maintain state. I understood 
that, that's why my mail talks of "per flow treatment" (not of 
state maintenance). I generally don't favor per flow features 
in backbone routers.

Regards,

Rudiger

| I see the proposed probing feature as optional that can be 
| used to solve the
| 
| ECMP routing problem that occurs during admission control.
| 
| But regarding your comment reagrding the per flow treatment, 
| when using the Router Alert option the PCN-interior-node does 
| not need to maintain any flow related information.
| If a PCN-interior-node operates in admission control state 
| then all packets that carry a Router Alert option, e.g., RSVP 
| PATH, will be PCN_marking encoded. In order to do this the 
| PCN-interior-node  does not need to maintain any flow related 
| information.
| 
| Bst regards,
| Georgios
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: donderdag 28 februari 2008 12:27
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > 
| > Hi Georgios,
| > 
| > | Even for excess rate marking the complexity added is not
| > signifficant.
| > | The Router Alert processing is already available in each router.
| > | The only additional complexity is related to the fact that the 
| > | PCN-interior-node will PCN_marking encode the packets that are 
| > | carrying a Router Alert option.
| > 
| > I understand your goal and your idea. I can't recall DiffServ to be a 
| > mechanism requiring RAO treatment from any router within a DiffServ 
| > domain. As PCN is a DiffServ based mechanism and I'm quite  happy with 
| > the idea not to depend on RAO evaluation. I look at the feature you 
| > propose as a possible option.
| > 
| > My companies network is operating with DiffServ and is using MPLS and 
| > ECMP. I'd like PCN to be standardised in a way not demanding complex 
| > software for the backbone routers (like RAO for MPLS - which you did 
| > not propose, but we also shouldn't end there). Preferably, per flow 
| > treatment intelligence should reside in edge boxes (and only there).
| > 
| > Regards,
| > 
| > Rudiger
| > 
| >  
| > | Best regards,
| > | Georgios
| > | 
| > | 
| > | > -----Original Message-----
| > | > From: [email-masked] [mailto:[email-masked]] On
| > | Behalf Of
| > | > Michael Menth
| > | > Sent: donderdag 28 februari 2008 11:50
| > | > To: Lars Eggert
| > | > Cc: pcn
| > | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > | > 
| > | > Hi Lars,
| > | > 
| > | > I just want to point out that this complexity is not due
| > to probing
| > | > itself but due to the use of excess rate marking for admission 
| > | > control.
| > | > There is no such increased complexity if probing is done in 
| > | > combination with exhaustive (threshold) marking for
| > | admission control.
| > | > 
| > | > Regards,
| > | > 
| > | >     Michael
| > | > 
| > | > Lars Eggert wrote:
| > | > > Hi,
| > | > >
| > | > > I'm not sure if I have fully digested this yet, but it
| > | > seems like this
| > | > > proposal defines different semantics for what the PCN
| > | marks mean to
| > | > > both the interior and egress nodes, depending on whether a
| > | > packet is a
| > | > > probe packet or not. That seems to add significant complexity.
| > | > >
| > | > > Lars
| > | > >
| > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote:
| > | > >
| > | > >   
| > | > >> Hi Phil
| > | > >>
| > | > >> Sorry for not being clear!
| > | > >>
| > | > >> As you know if ECMP routing is used then this might cause
| > | > problems on
| > | > >> the way of how admission control and flow termination
| > | > algorithms are
| > | > >> operating.
| > | > >>
| > | > >> The ECMP problem is related to the fact that flows can
| > | belong to a
| > | > >> certain ingress-egress-aggregate, which is maintained at
| > | > the ingress
| > | > >> adn egress and that operates in admission control
| > state or flow
| > | > >> termination state, but that due to the ECMP routing
| > they are not
| > | > >> passing through the congested node.
| > | > >>
| > | > >> Any measures that are taken on such flows will not solve the 
| > | > >> congestion problem, since such flows are not contributing
| > | > and causing
| > | > >> the congestion in the PCN-interior-node.
| > | > >>
| > | > >> Now when probing is used this problem can be solved 
| as follows.
| > | > >> When a PCN-interior-node is congested it MUST
| > | PCN_marking encode a
| > | > >> probe packet.
| > | > >>
| > | > >>
| > | > >> Thus if an egress operates, for a certain
| > | > ingress-egress-agrregate in
| > | > >> admission control state and it receives a probe packet
| > | > which belongs
| > | > >> to a flow associated with the same
| > | > ingress-egress-agrregate AND the
| > | > >> probe packet is PCN_marking encoded, then the egress knows
| > | > for sure
| > | > >> that the probe packet passed through one or more congested 
| > | > >> PCN-interior-nodes. In this case the probe packet, and
| > | > thus also the
| > | > >> requiesting flow can be rejected.
| > | > >>
| > | > >> If an egress operates, for a certain
| > ingress-egress-agrregate in
| > | > >> admission control state and it receives a probe packet
| > | > which belongs
| > | > >> to a flow associated with the same
| > | > ingress-egress-agrregate AND the
| > | > >> probe packet is marked as not congested PCN, then the
| > | egress knows
| > | > >> for sure that the probe packet HAS NOT PASSED through a
| > | congested
| > | > >> PCN-interior-node due to e.g., used ECMP routing. In
| > | this case the
| > | > >> probe packet can be accepted, since this flow, even it
| > | > belongs to the
| > | > >> ingress-egress-aggergate that operates in admission
| > | > control, is not
| > | > >> contributing and causing the congestion in the
| > PCN-interior-node.
| > | > >>
| > | > >>
| > | > >> Okay, but why one should provide the possibility to
| > | PCN-interior-
| > | > >> nodes to distinguish between probe packets and other PCN
| > | > aware user
| > | > >> packets?
| > | > >>
| > | > >> This is related to which admission control and flow
| > termination
| > | > >> algorithms and encodings are used in the PCN-interior-nodes.
| > | > >>
| > | > >> If an algorithm uses one encoding state for admission
| > | control and
| > | > >> another encoding state for flow termination then probably
| > | > it is not
| > | > >> required to provide the possibility to PC_interior-node to 
| > | > >> distinguish between probe packets and PCN aware user packets.
| > | > >> This is because when the PCN-interior-node that operates
| > | > in admission
| > | > >> control state will AM (admission control encoding state)
| > | > encode all
| > | > >> packets, i.e., probe packets and user packets.
| > | > >>
| > | > >> If an algorithm uses only one encoding state for
| > | admission control
| > | > >> and flow termionation, such as the ones used in the
| > | single marking
| > | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut
| > | be able to
| > | > >> distinguish between probe packets and user data packets.
| > | > >>
| > | > >> This is because both algorithms SM and LC-PCN are
| > | encoding packets
| > | > >> proportionaly to the excess rate.
| > | > >> This means that when the PCN-interior-node opetrates in
| > | admission
| > | > >> control state it will not SM mark all packets that 
| are passing 
| > | > >> through the node, but only a proportion that is needed to
| > | > represent
| > | > >> the excess rate. Thus if the PCN-interior-node will not
| > | > distinguish
| > | > >> between the probe packets and other PCN aware packets,
| > | > then it is not
| > | > >> certain that the probe packet will be SM marked when the 
| > | > >> PCN-interior-node operates in admission control state.
| > | > >> Now, if the probe packets carry a Router Alert option,
| > | and when in
| > | > >> Admission control state, the PCN-interior-node marks all
| > | > packets that
| > | > >> are carrying a Router Alert option, then the probe packet
| > | > will be for
| > | > >> sure marked.
| > | > >>
| > | > >> Hope that this clarifies your question!
| > | > >>
| > | > >> Best regards,
| > | > >> Georgios
| > | > >>
| > | > >>
| > | > >>
| > | > >>
| > | > >>
| > | > >>
| > | > >>     
| > | > >>> -----Original Message-----
| > | > >>> From: [email-masked] [mailto:[email-masked]]
| > | > >>> Sent: dinsdag 26 februari 2008 18:16
| > | > >>> To: [email-masked]; [email-masked]
| > | > >>> Cc: [email-masked]
| > | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > >>>
| > | > >>> Sorry, to repeat:
| > | > >>>
| > | > >>> I still have not the foggiest idea why on earth someone
| > | > would want
| > | > >>> or need or be interested in the interior node handling
| > | probe pkts
| > | > >>> differently from the way it handles probe pkts.
| > | > >>>
| > | > >>> So far you have answered a different question, about
| > whether it
| > | > >>> would be possible for someone to devise pcn so that an
| > | > interior node
| > | > >>> could distinguish probe pkts from data pkts. As you
| > | say, a router
| > | > >>> alert option could indeed be used.
| > | > >>>
| > | > >>>       
| > | > >>>> -----Original Message-----
| > | > >>>> From: Georgios Karagiannis [mailto:[email-masked]]
| > | > >>>> Sent: 26 February 2008 17:06
| > | > >>>> To: Eardley,PL,Philip,CXR9 R; [email-masked]
| > | > >>>> Cc: [email-masked]
| > | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > >>>>
| > | > >>>> Hi Phil
| > | > >>>>
| > | > >>>> * Regarding Routing NOT,
| > | > >>>> * Regarding scheduling, NOT
| > | > >>>> * Regarding PCN_marking, it could be handled differently:
| > | > >>>>
| > | > >>>>  ** if excess rate marking is used AND the
| > PCN-interior-node is
| > | > >>>>         
| > | > >>> congested
| > | > >>>       
| > | > >>>> AND
| > | > >>>>     the probe packet contains the ROUTER ALERT option THEN
| > | > >>>>     the probe packet can be distinguished from the other
| > | > >>>>         
| > | > >>> PCN packets,
| > | > >>>       
| > | > >>>>     and therefore it will be for sure PCN_marking encoded.
| > | > >>>>
| > | > >>>>  ** if excess rate marking is used AND the
| > PCN-interior-node is
| > | > >>>>         
| > | > >>> congested
| > | > >>>       
| > | > >>>> AND
| > | > >>>>     the probe packet DOES NOT contain the ROUTER 
| ALERT option
| > | > >>>>     THEN this MIGHT be PCN_marking encoded, or it
| > MIGHT not be
| > | > >>>> PCN_marking encoded. This depends
| > | > >>>>     on whether this probe packet is selected to represent
| > | > >>>>         
| > | > >>> the excess
| > | > >>>       
| > | > >>>> rate, or is not selected.
| > | > >>>>
| > | > >>>> Best regards,
| > | > >>>> Georgios
| > | > >>>>
| > | > >>>>
| > | > >>>>
| > | > >>>>
| > | > >>>>
| > | > >>>>         
| > | > >>>>> -----Original Message-----
| > | > >>>>> From: [email-masked] [mailto:[email-masked]]
| > | > >>>>> Sent: dinsdag 26 februari 2008 17:45
| > | > >>>>> To: [email-masked]; [email-masked]
| > | > >>>>> Cc: [email-masked]
| > | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > >>>>>
| > | > >>>>> But why would the interior node *need* to distinguish it
| > | > >>>>>           
| > | > >>> from other
| > | > >>>       
| > | > >>>>> pcn pkts?
| > | > >>>>>
| > | > >>>>> And even if you have got router alert, the architecture
| > | > >>>>>           
| > | > >>> draft says:
| > | > >>>       
| > | > >>>>> "must be handled the same as (ordinary data) PCN-packets,
| > | > >>>>>           
| > | > >>> in terms
| > | > >>>       
| > | > >>>>> of routing, scheduling and PCN-marking."
| > | > >>>>> Even though your router alert's got it in slow path, will
| > | > >>>>>           
| > | > >>> it handle
| > | > >>>       
| > | > >>>>> it any differently in terms of routing scehdulign &
| > | pcn-marking?
| > | > >>>>>
| > | > >>>>>
| > | > >>>>>           
| > | > >> _______________________________________________
| > | > >> PCN mailing list
| > | > >> [email-masked]
| > | > >> https://www.ietf.org/mailman/listinfo/pcn
| > | > >>     
| > | > >
| > | > > _______________________________________________
| > | > > PCN mailing list
| > | > > [email-masked]
| > | > > https://www.ietf.org/mailman/listinfo/pcn
| > | > >   
| > | > 
| > | > --
| > | > 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://www.ietf.org/mailman/listinfo/pcn
| > | > 
| > | 
| > | 
| > | _______________________________________________
| > | PCN mailing list
| > | [email-masked]
| > | https://www.ietf.org/mailman/listinfo/pcn
| > | 
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 12:48:12 +0100

Hi Ruediger

But is the Router Alert option processing, per flow treatment?
Any packet that belongs to any flow and carries a Router Alert option is
treated 
in the same way as all other packets that are carrying a Router Alert
option.

Or am I missing something here?

Best regards,
Georgios

> Sent: donderdag 28 februari 2008 12:44
> sure, the routers aren't required to maintain state. I 
> understood that, that's why my mail talks of "per flow 
> treatment" (not of state maintenance). I generally don't 
> favor per flow features in backbone routers.
> 
> Regards,
> 
> Rudiger
> 
> | I see the proposed probing feature as optional that can be used to 
> | solve the
> | 
> | But regarding your comment reagrding the per flow treatment, when 
> | using the Router Alert option the PCN-interior-node does 
> not need to 
> | maintain any flow related information.
> | If a PCN-interior-node operates in admission control state then all 
> | packets that carry a Router Alert option, e.g., RSVP PATH, will be 
> | PCN_marking encoded. In order to do this the 
> PCN-interior-node  does 
> | > I understand your goal and your idea. I can't recall 
> DiffServ to be 
> | > a mechanism requiring RAO treatment from any router within a 
> | > DiffServ domain. As PCN is a DiffServ based mechanism and 
> I'm quite  
> | > happy with the idea not to depend on RAO evaluation. I 
> look at the 
> | > feature you propose as a possible option.
> | > 
> | > My companies network is operating with DiffServ and is using MPLS 
> | > and ECMP. I'd like PCN to be standardised in a way not demanding 
> | > complex software for the backbone routers (like RAO for 
> MPLS - which 
> | > you did not propose, but we also shouldn't end there). 
> Preferably, 
> | > per flow treatment intelligence should reside in edge 
> boxes (and only there).
> | > 
> | > Regards,
> | > 
> | > Rudiger
> | > 
> | >  
> | > | Best regards,
> | > | Georgios
> | > | 
> | > |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 28 Feb 2008 13:06:11 +0100

Hi Georgios, 

that may be a philosophical question. My backbone engineering 
department probably answers "yes" to the question, whether 
the RAO means per flow treatment. I didn't ask them, but my 
impression is that user datagrams are supposed to remain on 
the fast path within our backbone.

Regards,

Rudiger

| But is the Router Alert option processing, per flow treatment?
| Any packet that belongs to any flow and carries a Router 
| Alert option is treated in the same way as all other packets 
| that are carrying a Router Alert option.
| 
| Or am I missing something here?
| 
| Best regards,
| Georgios
| 
|  
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: donderdag 28 februari 2008 12:44
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > 
| > Hi Georgios,
| > 
| > sure, the routers aren't required to maintain state. I understood 
| > that, that's why my mail talks of "per flow treatment" (not 
| of state 
| > maintenance). I generally don't favor per flow features in backbone 
| > routers.
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > | I see the proposed probing feature as optional that can 
| be used to 
| > | solve the
| > | 
| > | ECMP routing problem that occurs during admission control.
| > | 
| > | But regarding your comment reagrding the per flow treatment, when 
| > | using the Router Alert option the PCN-interior-node does
| > not need to
| > | maintain any flow related information.
| > | If a PCN-interior-node operates in admission control 
| state then all 
| > | packets that carry a Router Alert option, e.g., RSVP 
| PATH, will be 
| > | PCN_marking encoded. In order to do this the
| > PCN-interior-node  does
| > | not need to maintain any flow related information.
| > | 
| > | Bst regards,
| > | Georgios
| > | 
| > | > -----Original Message-----
| > | > From: Geib, Ruediger [mailto:[email-masked]]
| > | > Sent: donderdag 28 februari 2008 12:27
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > 
| > | > Hi Georgios,
| > | > 
| > | > | Even for excess rate marking the complexity added is not
| > | > signifficant.
| > | > | The Router Alert processing is already available in 
| each router.
| > | > | The only additional complexity is related to the fact 
| that the 
| > | > | PCN-interior-node will PCN_marking encode the packets 
| that are 
| > | > | carrying a Router Alert option.
| > | > 
| > | > I understand your goal and your idea. I can't recall
| > DiffServ to be
| > | > a mechanism requiring RAO treatment from any router within a 
| > | > DiffServ domain. As PCN is a DiffServ based mechanism and
| > I'm quite
| > | > happy with the idea not to depend on RAO evaluation. I
| > look at the
| > | > feature you propose as a possible option.
| > | > 
| > | > My companies network is operating with DiffServ and is 
| using MPLS 
| > | > and ECMP. I'd like PCN to be standardised in a way not 
| demanding 
| > | > complex software for the backbone routers (like RAO for
| > MPLS - which
| > | > you did not propose, but we also shouldn't end there). 
| > Preferably,
| > | > per flow treatment intelligence should reside in edge
| > boxes (and only there).
| > | > 
| > | > Regards,
| > | > 
| > | > Rudiger
| > | > 
| > | >  
| > | > | Best regards,
| > | > | Georgios
| > | > | 
| > | > | 
| > | > | > -----Original Message-----
| > | > | > From: [email-masked] [mailto:[email-masked]] On
| > | > | Behalf Of
| > | > | > Michael Menth
| > | > | > Sent: donderdag 28 februari 2008 11:50
| > | > | > To: Lars Eggert
| > | > | > Cc: pcn
| > | > | > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > | > | > 
| > | > | > Hi Lars,
| > | > | > 
| > | > | > I just want to point out that this complexity is not due
| > | > to probing
| > | > | > itself but due to the use of excess rate marking for
| > admission
| > | > | > control.
| > | > | > There is no such increased complexity if probing is done in 
| > | > | > combination with exhaustive (threshold) marking for
| > | > | admission control.
| > | > | > 
| > | > | > Regards,
| > | > | > 
| > | > | >     Michael
| > | > | > 
| > | > | > Lars Eggert wrote:
| > | > | > > Hi,
| > | > | > >
| > | > | > > I'm not sure if I have fully digested this yet, but it
| > | > | > seems like this
| > | > | > > proposal defines different semantics for what the PCN
| > | > | marks mean to
| > | > | > > both the interior and egress nodes, depending on whether a
| > | > | > packet is a
| > | > | > > probe packet or not. That seems to add significant
| > complexity.
| > | > | > >
| > | > | > > Lars
| > | > | > >
| > | > | > > On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote:
| > | > | > >
| > | > | > >   
| > | > | > >> Hi Phil
| > | > | > >>
| > | > | > >> Sorry for not being clear!
| > | > | > >>
| > | > | > >> As you know if ECMP routing is used then this might cause
| > | > | > problems on
| > | > | > >> the way of how admission control and flow termination
| > | > | > algorithms are
| > | > | > >> operating.
| > | > | > >>
| > | > | > >> The ECMP problem is related to the fact that flows can
| > | > | belong to a
| > | > | > >> certain ingress-egress-aggregate, which is maintained at
| > | > | > the ingress
| > | > | > >> adn egress and that operates in admission control
| > | > state or flow
| > | > | > >> termination state, but that due to the ECMP routing
| > | > they are not
| > | > | > >> passing through the congested node.
| > | > | > >>
| > | > | > >> Any measures that are taken on such flows will not
| > solve the
| > | > | > >> congestion problem, since such flows are not contributing
| > | > | > and causing
| > | > | > >> the congestion in the PCN-interior-node.
| > | > | > >>
| > | > | > >> Now when probing is used this problem can be solved
| > | as follows.
| > | > | > >> When a PCN-interior-node is congested it MUST
| > | > | PCN_marking encode a
| > | > | > >> probe packet.
| > | > | > >>
| > | > | > >>
| > | > | > >> Thus if an egress operates, for a certain
| > | > | > ingress-egress-agrregate in
| > | > | > >> admission control state and it receives a probe packet
| > | > | > which belongs
| > | > | > >> to a flow associated with the same
| > | > | > ingress-egress-agrregate AND the
| > | > | > >> probe packet is PCN_marking encoded, then the 
| egress knows
| > | > | > for sure
| > | > | > >> that the probe packet passed through one or more 
| congested 
| > | > | > >> PCN-interior-nodes. In this case the probe packet, and
| > | > | > thus also the
| > | > | > >> requiesting flow can be rejected.
| > | > | > >>
| > | > | > >> If an egress operates, for a certain
| > | > ingress-egress-agrregate in
| > | > | > >> admission control state and it receives a probe packet
| > | > | > which belongs
| > | > | > >> to a flow associated with the same
| > | > | > ingress-egress-agrregate AND the
| > | > | > >> probe packet is marked as not congested PCN, then the
| > | > | egress knows
| > | > | > >> for sure that the probe packet HAS NOT PASSED through a
| > | > | congested
| > | > | > >> PCN-interior-node due to e.g., used ECMP routing. In
| > | > | this case the
| > | > | > >> probe packet can be accepted, since this flow, even it
| > | > | > belongs to the
| > | > | > >> ingress-egress-aggergate that operates in admission
| > | > | > control, is not
| > | > | > >> contributing and causing the congestion in the
| > | > PCN-interior-node.
| > | > | > >>
| > | > | > >>
| > | > | > >> Okay, but why one should provide the possibility to
| > | > | PCN-interior-
| > | > | > >> nodes to distinguish between probe packets and other PCN
| > | > | > aware user
| > | > | > >> packets?
| > | > | > >>
| > | > | > >> This is related to which admission control and flow
| > | > termination
| > | > | > >> algorithms and encodings are used in the
| > PCN-interior-nodes.
| > | > | > >>
| > | > | > >> If an algorithm uses one encoding state for admission
| > | > | control and
| > | > | > >> another encoding state for flow termination then probably
| > | > | > it is not
| > | > | > >> required to provide the possibility to 
| PC_interior-node to 
| > | > | > >> distinguish between probe packets and PCN aware
| > user packets.
| > | > | > >> This is because when the PCN-interior-node that operates
| > | > | > in admission
| > | > | > >> control state will AM (admission control encoding state)
| > | > | > encode all
| > | > | > >> packets, i.e., probe packets and user packets.
| > | > | > >>
| > | > | > >> If an algorithm uses only one encoding state for
| > | > | admission control
| > | > | > >> and flow termionation, such as the ones used in the
| > | > | single marking
| > | > | > >> (SM) and LC-PCN drafts, then the PCN-interior-node msut
| > | > | be able to
| > | > | > >> distinguish between probe packets and user data packets.
| > | > | > >>
| > | > | > >> This is because both algorithms SM and LC-PCN are
| > | > | encoding packets
| > | > | > >> proportionaly to the excess rate.
| > | > | > >> This means that when the PCN-interior-node opetrates in
| > | > | admission
| > | > | > >> control state it will not SM mark all packets that
| > | are passing
| > | > | > >> through the node, but only a proportion that is needed to
| > | > | > represent
| > | > | > >> the excess rate. Thus if the PCN-interior-node will not
| > | > | > distinguish
| > | > | > >> between the probe packets and other PCN aware packets,
| > | > | > then it is not
| > | > | > >> certain that the probe packet will be SM marked when the 
| > | > | > >> PCN-interior-node operates in admission control state.
| > | > | > >> Now, if the probe packets carry a Router Alert option,
| > | > | and when in
| > | > | > >> Admission control state, the PCN-interior-node marks all
| > | > | > packets that
| > | > | > >> are carrying a Router Alert option, then the probe packet
| > | > | > will be for
| > | > | > >> sure marked.
| > | > | > >>
| > | > | > >> Hope that this clarifies your question!
| > | > | > >>
| > | > | > >> Best regards,
| > | > | > >> Georgios
| > | > | > >>
| > | > | > >>
| > | > | > >>
| > | > | > >>
| > | > | > >>
| > | > | > >>
| > | > | > >>     
| > | > | > >>> -----Original Message-----
| > | > | > >>> From: [email-masked] 
| [mailto:[email-masked]]
| > | > | > >>> Sent: dinsdag 26 februari 2008 18:16
| > | > | > >>> To: [email-masked]; [email-masked]
| > | > | > >>> Cc: [email-masked]
| > | > | > >>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > | > >>>
| > | > | > >>> Sorry, to repeat:
| > | > | > >>>
| > | > | > >>> I still have not the foggiest idea why on earth someone
| > | > | > would want
| > | > | > >>> or need or be interested in the interior node handling
| > | > | probe pkts
| > | > | > >>> differently from the way it handles probe pkts.
| > | > | > >>>
| > | > | > >>> So far you have answered a different question, about
| > | > whether it
| > | > | > >>> would be possible for someone to devise pcn so that an
| > | > | > interior node
| > | > | > >>> could distinguish probe pkts from data pkts. As you
| > | > | say, a router
| > | > | > >>> alert option could indeed be used.
| > | > | > >>>
| > | > | > >>>       
| > | > | > >>>> -----Original Message-----
| > | > | > >>>> From: Georgios Karagiannis
| > [mailto:[email-masked]]
| > | > | > >>>> Sent: 26 February 2008 17:06
| > | > | > >>>> To: Eardley,PL,Philip,CXR9 R; [email-masked]
| > | > | > >>>> Cc: [email-masked]
| > | > | > >>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > | > >>>>
| > | > | > >>>> Hi Phil
| > | > | > >>>>
| > | > | > >>>> * Regarding Routing NOT,
| > | > | > >>>> * Regarding scheduling, NOT
| > | > | > >>>> * Regarding PCN_marking, it could be handled 
| differently:
| > | > | > >>>>
| > | > | > >>>>  ** if excess rate marking is used AND the
| > | > PCN-interior-node is
| > | > | > >>>>         
| > | > | > >>> congested
| > | > | > >>>       
| > | > | > >>>> AND
| > | > | > >>>>     the probe packet contains the ROUTER ALERT
| > option THEN
| > | > | > >>>>     the probe packet can be distinguished from 
| the other
| > | > | > >>>>         
| > | > | > >>> PCN packets,
| > | > | > >>>       
| > | > | > >>>>     and therefore it will be for sure
| > PCN_marking encoded.
| > | > | > >>>>
| > | > | > >>>>  ** if excess rate marking is used AND the
| > | > PCN-interior-node is
| > | > | > >>>>         
| > | > | > >>> congested
| > | > | > >>>       
| > | > | > >>>> AND
| > | > | > >>>>     the probe packet DOES NOT contain the ROUTER
| > | ALERT option
| > | > | > >>>>     THEN this MIGHT be PCN_marking encoded, or it
| > | > MIGHT not be
| > | > | > >>>> PCN_marking encoded. This depends
| > | > | > >>>>     on whether this probe packet is selected 
| to represent
| > | > | > >>>>         
| > | > | > >>> the excess
| > | > | > >>>       
| > | > | > >>>> rate, or is not selected.
| > | > | > >>>>
| > | > | > >>>> Best regards,
| > | > | > >>>> Georgios
| > | > | > >>>>
| > | > | > >>>>
| > | > | > >>>>
| > | > | > >>>>
| > | > | > >>>>
| > | > | > >>>>         
| > | > | > >>>>> -----Original Message-----
| > | > | > >>>>> From: [email-masked]
| > [mailto:[email-masked]]
| > | > | > >>>>> Sent: dinsdag 26 februari 2008 17:45
| > | > | > >>>>> To: [email-masked]; [email-masked]
| > | > | > >>>>> Cc: [email-masked]
| > | > | > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > | > | > >>>>>
| > | > | > >>>>> But why would the interior node *need* to 
| distinguish it
| > | > | > >>>>>           
| > | > | > >>> from other
| > | > | > >>>       
| > | > | > >>>>> pcn pkts?
| > | > | > >>>>>
| > | > | > >>>>> And even if you have got router alert, the 
| architecture
| > | > | > >>>>>           
| > | > | > >>> draft says:
| > | > | > >>>       
| > | > | > >>>>> "must be handled the same as (ordinary data)
| > PCN-packets,
| > | > | > >>>>>           
| > | > | > >>> in terms
| > | > | > >>>       
| > | > | > >>>>> of routing, scheduling and PCN-marking."
| > | > | > >>>>> Even though your router alert's got it in slow
| > path, will
| > | > | > >>>>>           
| > | > | > >>> it handle
| > | > | > >>>       
| > | > | > >>>>> it any differently in terms of routing scehdulign &
| > | > | pcn-marking?
| > | > | > >>>>>
| > | > | > >>>>>
| > | > | > >>>>>           
| > | > | > >> _______________________________________________
| > | > | > >> PCN mailing list
| > | > | > >> [email-masked]
| > | > | > >> https://www.ietf.org/mailman/listinfo/pcn
| > | > | > >>     
| > | > | > >
| > | > | > > _______________________________________________
| > | > | > > PCN mailing list
| > | > | > > [email-masked]
| > | > | > > https://www.ietf.org/mailman/listinfo/pcn
| > | > | > >   
| > | > | > 
| > | > | > --
| > | > | > 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://www.ietf.org/mailman/listinfo/pcn
| > | > | > 
| > | > | 
| > | > | 
| > | > | _______________________________________________
| > | > | PCN mailing list
| > | > | [email-masked]
| > | > | https://www.ietf.org/mailman/listinfo/pcn
| > | > | 
| > | > 
| > | 
| > | 
| > | 
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 28 Feb 2008 10:35:33 -0500

Hi Michael, 

You lost me on this.  The discussion seems to be centered around the
complexities of appropriately forwarding and processing probe packets in
the core.  What exactly does excess rate marking has to do with it? (I
do understand the point that excess rate marking needs more probes to
work reliably than threshold-vased/aka vertuall-queue-based marking - I
just do not see the connection of this point to the discussion it seems
to relate to).

If I am missing your point (or the point of the discussion) - which is
quite possible as I am reading the thread backwards - I would much
appreciate a clarification.

Anna  

> Sent: Thursday, February 28, 2008 5:50 AM
> To: Lars Eggert
> Cc: pcn

---

From: Michael Menth <[email-masked]>
Date: Thu, 28 Feb 2008 16:50:37 +0100

Hi Anna,

> just do not see the connection of this point to the discussion it seems

Georgios proposes to do excess rate marking and to avoid multiple 
probes, he wants to make sure that probe packets are always AM-marked 
when a link is precongested with regard to the admissible rate. He 
solves this problem using the router alert option (RAO) taking packets 
off the fast path. This solves the problem you have described above 
(which is caused by excess rate marking), but introduces the problem of 
RAO. That impacts the forwarding of the packets as they need special 
handling by the routers. The origin of this thread was that the 
architecture draft said that all pcn packets should be treated in the 
same way by PCN nodes which is no longer the case for normal data packet 
and PCN packets.

Regards,

    Michael

>>> I'm not sure if I have fully digested this yet, but it 
>>>       
>> seems like this 
>>     
>>> both the interior and egress nodes, depending on whether a 
>>>       
>> packet is a 
>>     
>>>> congestion problem, since such flows are not contributing 
>>>>         
>> and causing 
>>     
>>>> Thus if an egress operates, for a certain 
>>>>         
>> ingress-egress-agrregate in 
>>     
>>>> probe packet is PCN_marking encoded, then the egress knows 
>>>>         
>> for sure 
>>     
>>>> ingress-egress-aggergate that operates in admission 
>>>>         
>> control, is not 
>>     
>>>> another encoding state for flow termination then probably 
>>>>         
>> it is not 
>>     
>>>> This is because when the PCN-interior-node that operates 
>>>>         
>> in admission 
>>     
>>>> control state will AM (admission control encoding state) 
>>>>         
>> encode all 
>>

---

From: Michael Menth <[email-masked]>
Date: Thu, 28 Feb 2008 16:58:58 +0100

forgot a piece ...

Michael Menth wrote:
> off the fast path.
... and making sure that every such probe packet is marked when 
AR-precongestion occurs.

>  This solves the problem you have described above

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 Feb 2008 18:06:16 +0200

Hi,

On 2008-2-28, at 17:50, ext Michael Menth wrote:
> probes, he wants to make sure that probe packets are always AM- 
> marked when a link is precongested with regard to the admissible  
> rate. He solves this problem using the router alert option (RAO)  
> taking packets off the fast path. This solves the problem you have  
> described above (which is caused by excess rate marking), but  
> introduces the problem of RAO. That impacts the forwarding of the  
> packets as they need special handling by the routers. The origin of  
> this thread was that the architecture draft said that all pcn  
> packets should be treated in the same way by PCN nodes which is no  
> longer the case for normal data packet and PCN packets.

one related question is whether RAO packets actually receive the same  
ECMP treatment that non-RAO packets would receive, since they're being  
kicked out of the fast path, where ECMP happens.

Anyone know how routers deal with this?

(From what I understand from the discussions with the routing ADs on  
NSIS' use of RAO, relying on RAO pretty much guarantees serious  
deployment issues.)

Lars

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 28 Feb 2008 11:07:36 -0500

Hi Michael,

Ah - that makes perfect sense. Thank you for the concise summary.

Anna  

> Sent: Thursday, February 28, 2008 10:51 AM
> To: Anna Charny (acharny)
> Cc: Lars Eggert; pcn
> > complexities of appropriately forwarding and processing 
> probe packets 
> > in the core.  What exactly does excess rate marking has to 
> do with it? 
> > (I do understand the point that excess rate marking needs 
> more probes 
> > to work reliably than threshold-vased/aka 
> vertuall-queue-based marking 
> > - I just do not see the connection of this point to the 
> discussion it 
> > seems to relate to).
> >   
> 
> Georgios proposes to do excess rate marking and to avoid 
> multiple probes, he wants to make sure that probe packets are 
> always AM-marked when a link is precongested with regard to 
> the admissible rate. He solves this problem using the router 
> alert option (RAO) taking packets off the fast path. This 
> solves the problem you have described above (which is caused 
> by excess rate marking), but introduces the problem of RAO. 
> That impacts the forwarding of the packets as they need 
> special handling by the routers. The origin of this thread 
> was that the architecture draft said that all pcn packets 
> should be treated in the same way by PCN nodes which is no 
> >> Michael Menth
> egress knows 
> PCN-interior- 
> >> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> >> Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> >> room B206

---

From: <[email-masked]>
Date: Thu, 28 Feb 2008 18:52:42 -0000

Hi

Thanks for clarifying Georgios. interesting idea. 

Just to go back to the basic reason why single marking's attractive.
[1] single marking behaviour on interior routers
[2] only single encoding needed

your idea at first sight has just one marking behaviour, ie excess rate
marking. Indeed, it only has one token bucket. However, it does have
extra code/complexity in order to do threshold marking for probe pkts,
and this involves the pkt being processed on the slow path within a
router. I guess this complexity is for pkt classification &
PCN-encoding, rather than for the PCN-metering function. 

in terms of encoding, it does have a second encoding, but it uses RAO
bits rather than ECN/DSCP bits. 

I worry a bit about security attacks (because probe pkts can now be
identified) and about deploability barrier (will operators deploy
something that slows all their core routers - after all we claimed one
advantage of PCN over hop-by-hop rsvp is that your core routers are
really simple, don't have to do any difficult processing...

phil

Anna
> Charny (acharny)
> Sent: 28 February 2008 16:08
> To: [email-masked]
> Cc: pcn
it

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 29 Feb 2008 09:01:53 +0100

Hi Phil,

as mentioned in another thread: the operator I'm working for is 
currently not interested in supporting protocols requiring RAO 
processing in backbone routers.

Please also keep in mind MPLS friendliness - RAO based 
mechanisms are useless in that case. DiffServ mechanisms 
are generally more MPLS friendly than IntServ mechanisms.

Georgios idea may have merits and I don't oppose further 
development fundamentally. But it shouldn't be more than 
an option (on which Georgios seems to agree).
Taking a security viewpoint, messages requiring slow 
path processing by backbone routers may have to carry 
some authentification information (which won't make 
slow path processing faster) and may also have to be 
rate limited by backbone routers. 

Regards,

Rudiger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of [email-masked]
| Sent: Thursday, February 28, 2008 7:53 PM
| To: [email-masked]; [email-masked]
| Cc: [email-masked]
| Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| 
| Hi
| 
| Thanks for clarifying Georgios. interesting idea. 
| 
| Just to go back to the basic reason why single marking's attractive.
| [1] single marking behaviour on interior routers [2] only 
| single encoding needed
| 
| your idea at first sight has just one marking behaviour, ie 
| excess rate marking. Indeed, it only has one token bucket. 
| However, it does have extra code/complexity in order to do 
| threshold marking for probe pkts, and this involves the pkt 
| being processed on the slow path within a router. I guess 
| this complexity is for pkt classification & PCN-encoding, 
| rather than for the PCN-metering function. 
| 
| in terms of encoding, it does have a second encoding, but it 
| uses RAO bits rather than ECN/DSCP bits. 
| 
| I worry a bit about security attacks (because probe pkts can now be
| identified) and about deploability barrier (will operators 
| deploy something that slows all their core routers - after 
| all we claimed one advantage of PCN over hop-by-hop rsvp is 
| that your core routers are really simple, don't have to do 
| any difficult processing...
| 
| phil
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of
| Anna
| > Charny (acharny)
| > Sent: 28 February 2008 16:08
| > To: [email-masked]
| > Cc: pcn
| > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > 
| > Hi Michael,
| > 
| > Ah - that makes perfect sense. Thank you for the concise summary.
| > 
| > Anna
| > 
| > > -----Original Message-----
| > > From: Michael Menth [mailto:[email-masked]]
| > > Sent: Thursday, February 28, 2008 10:51 AM
| > > To: Anna Charny (acharny)
| > > Cc: Lars Eggert; pcn
| > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > >
| > > Hi Anna,
| > >
| > > Anna Charny (acharny) wrote:
| > > > Hi Michael,
| > > >
| > > > You lost me on this.  The discussion seems to be centered
| > > around the
| > > > complexities of appropriately forwarding and processing
| > > probe packets
| > > > in the core.  What exactly does excess rate marking has to
| > > do with it?
| > > > (I do understand the point that excess rate marking needs
| > > more probes
| > > > to work reliably than threshold-vased/aka
| > > vertuall-queue-based marking
| > > > - I just do not see the connection of this point to the
| > > discussion it
| > > > seems to relate to).
| > > >
| > >
| > > Georgios proposes to do excess rate marking and to avoid multiple 
| > > probes, he wants to make sure that probe packets are always 
| > > AM-marked when a link is precongested with regard to the 
| admissible 
| > > rate. He solves this problem using the router alert option (RAO) 
| > > taking packets off the fast path. This solves the problem 
| you have 
| > > described above (which is caused by excess rate marking), but 
| > > introduces the problem of RAO.
| > > That impacts the forwarding of the packets as they need special 
| > > handling by the routers. The origin of this thread was that the 
| > > architecture draft said that all pcn packets should be treated in 
| > > the same way by PCN nodes which is no longer the case for normal 
| > > data packet and PCN packets.
| > >
| > > Regards,
| > >
| > >     Michael
| > >
| > > > If I am missing your point (or the point of the discussion)
| > > - which is
| > > > quite possible as I am reading the thread backwards - I 
| would much 
| > > > appreciate a clarification.
| > > >
| > > > Anna
| > > >
| > > >
| > > >> -----Original Message-----
| > > >> From: [email-masked] [mailto:[email-masked]]
| > > On Behalf Of
| > > >> Michael Menth
| > > >> Sent: Thursday, February 28, 2008 5:50 AM
| > > >> To: Lars Eggert
| > > >> Cc: pcn
| > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > > >>
| > > >> Hi Lars,
| > > >>
| > > >> I just want to point out that this complexity is not due
| > > to probing
| > > >> itself but due to the use of excess rate marking for admission 
| > > >> control.
| > > >> There is no such increased complexity if probing is done in 
| > > >> combination with exhaustive (threshold) marking for
| > > admission control.
| > > >>
| > > >> Regards,
| > > >>
| > > >>     Michael
| > > >>
| > > >> Lars Eggert wrote:
| > > >>
| > > >>> Hi,
| > > >>>
| > > >>> I'm not sure if I have fully digested this yet, but it
| > > >>>
| > > >> seems like this
| > > >>
| > > >>> proposal defines different semantics for what the PCN
| > > marks mean to
| > > >>> both the interior and egress nodes, depending on whether a
| > > >>>
| > > >> packet is a
| > > >>
| > > >>> probe packet or not. That seems to add significant complexity.
| > > >>>
| > > >>> Lars
| > > >>>
| > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote:
| > > >>>
| > > >>>
| > > >>>
| > > >>>> Hi Phil
| > > >>>>
| > > >>>> Sorry for not being clear!
| > > >>>>
| > > >>>> As you know if ECMP routing is used then this might cause
| > > >>>>
| > > >> problems on
| > > >>
| > > >>>> the way of how admission control and flow termination
| > > >>>>
| > > >> algorithms are
| > > >>
| > > >>>> operating.
| > > >>>>
| > > >>>> The ECMP problem is related to the fact that flows can
| > > belong to a
| > > >>>> certain ingress-egress-aggregate, which is maintained at
| > > >>>>
| > > >> the ingress
| > > >>
| > > >>>> adn egress and that operates in admission control 
| state or flow 
| > > >>>> termination state, but that due to the ECMP routing they are
| not
| > > >>>> passing through the congested node.
| > > >>>>
| > > >>>> Any measures that are taken on such flows will not solve the 
| > > >>>> congestion problem, since such flows are not contributing
| > > >>>>
| > > >> and causing
| > > >>
| > > >>>> the congestion in the PCN-interior-node.
| > > >>>>
| > > >>>> Now when probing is used this problem can be solved 
| as follows.
| > > >>>> When a PCN-interior-node is congested it MUST
| > > PCN_marking encode a
| > > >>>> probe packet.
| > > >>>>
| > > >>>>
| > > >>>> Thus if an egress operates, for a certain
| > > >>>>
| > > >> ingress-egress-agrregate in
| > > >>
| > > >>>> admission control state and it receives a probe packet
| > > >>>>
| > > >> which belongs
| > > >>
| > > >>>> to a flow associated with the same
| > > >>>>
| > > >> ingress-egress-agrregate AND the
| > > >>
| > > >>>> probe packet is PCN_marking encoded, then the egress knows
| > > >>>>
| > > >> for sure
| > > >>
| > > >>>> that the probe packet passed through one or more congested 
| > > >>>> PCN-interior-nodes. In this case the probe packet, and
| > > >>>>
| > > >> thus also the
| > > >>
| > > >>>> requiesting flow can be rejected.
| > > >>>>
| > > >>>> If an egress operates, for a certain ingress-egress-agrregate
| in
| > > >>>> admission control state and it receives a probe packet
| > > >>>>
| > > >> which belongs
| > > >>
| > > >>>> to a flow associated with the same
| > > >>>>
| > > >> ingress-egress-agrregate AND the
| > > >>
| > > >>>> probe packet is marked as not congested PCN, then the
| > > egress knows
| > > >>>> for sure that the probe packet HAS NOT PASSED through a
| > > congested
| > > >>>> PCN-interior-node due to e.g., used ECMP routing. In
| > > this case the
| > > >>>> probe packet can be accepted, since this flow, even it
| > > >>>>
| > > >> belongs to the
| > > >>
| > > >>>> ingress-egress-aggergate that operates in admission
| > > >>>>
| > > >> control, is not
| > > >>
| > > >>>> contributing and causing the congestion in the
| PCN-interior-node.
| > > >>>>
| > > >>>>
| > > >>>> Okay, but why one should provide the possibility to
| > > PCN-interior-
| > > >>>> nodes to distinguish between probe packets and other PCN
| > > >>>>
| > > >> aware user
| > > >>
| > > >>>> packets?
| > > >>>>
| > > >>>> This is related to which admission control and flow 
| termination 
| > > >>>> algorithms and encodings are used in the PCN-interior-nodes.
| > > >>>>
| > > >>>> If an algorithm uses one encoding state for admission
| > > control and
| > > >>>> another encoding state for flow termination then probably
| > > >>>>
| > > >> it is not
| > > >>
| > > >>>> required to provide the possibility to PC_interior-node to 
| > > >>>> distinguish between probe packets and PCN aware user packets.
| > > >>>> This is because when the PCN-interior-node that operates
| > > >>>>
| > > >> in admission
| > > >>
| > > >>>> control state will AM (admission control encoding state)
| > > >>>>
| > > >> encode all
| > > >>
| > > >>>> packets, i.e., probe packets and user packets.
| > > >>>>
| > > >>>> If an algorithm uses only one encoding state for
| > > admission control
| > > >>>> and flow termionation, such as the ones used in the
| > > single marking
| > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut
| > > be able to
| > > >>>> distinguish between probe packets and user data packets.
| > > >>>>
| > > >>>> This is because both algorithms SM and LC-PCN are
| > > encoding packets
| > > >>>> proportionaly to the excess rate.
| > > >>>> This means that when the PCN-interior-node opetrates in
| > > admission
| > > >>>> control state it will not SM mark all packets that 
| are passing 
| > > >>>> through the node, but only a proportion that is needed to
| > > >>>>
| > > >> represent
| > > >>
| > > >>>> the excess rate. Thus if the PCN-interior-node will not
| > > >>>>
| > > >> distinguish
| > > >>
| > > >>>> between the probe packets and other PCN aware packets,
| > > >>>>
| > > >> then it is not
| > > >>
| > > >>>> certain that the probe packet will be SM marked when the 
| > > >>>> PCN-interior-node operates in admission control state.
| > > >>>> Now, if the probe packets carry a Router Alert option,
| > > and when in
| > > >>>> Admission control state, the PCN-interior-node marks all
| > > >>>>
| > > >> packets that
| > > >>
| > > >>>> are carrying a Router Alert option, then the probe packet
| > > >>>>
| > > >> will be for
| > > >>
| > > >>>> sure marked.
| > > >>>>
| > > >>>> Hope that this clarifies your question!
| > > >>>>
| > > >>>> Best regards,
| > > >>>> Georgios
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>> -----Original Message-----
| > > >>>>> From: [email-masked] [mailto:[email-masked]]
| > > >>>>> Sent: dinsdag 26 februari 2008 18:16
| > > >>>>> To: [email-masked]; [email-masked]
| > > >>>>> Cc: [email-masked]
| > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > > >>>>>
| > > >>>>> Sorry, to repeat:
| > > >>>>>
| > > >>>>> I still have not the foggiest idea why on earth someone
| > > >>>>>
| > > >> would want
| > > >>
| > > >>>>> or need or be interested in the interior node handling
| > > probe pkts
| > > >>>>> differently from the way it handles probe pkts.
| > > >>>>>
| > > >>>>> So far you have answered a different question, about whether
| it
| > > >>>>> would be possible for someone to devise pcn so that an
| > > >>>>>
| > > >> interior node
| > > >>
| > > >>>>> could distinguish probe pkts from data pkts. As you
| > > say, a router
| > > >>>>> alert option could indeed be used.
| > > >>>>>
| > > >>>>>
| > > >>>>>
| > > >>>>>> -----Original Message-----
| > > >>>>>> From: Georgios Karagiannis [mailto:[email-masked]]
| > > >>>>>> Sent: 26 February 2008 17:06
| > > >>>>>> To: Eardley,PL,Philip,CXR9 R; [email-masked]
| > > >>>>>> Cc: [email-masked]
| > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > > >>>>>>
| > > >>>>>> Hi Phil
| > > >>>>>>
| > > >>>>>> * Regarding Routing NOT,
| > > >>>>>> * Regarding scheduling, NOT
| > > >>>>>> * Regarding PCN_marking, it could be handled differently:
| > > >>>>>>
| > > >>>>>>  ** if excess rate marking is used AND the 
| PCN-interior-node
| is
| > > >>>>>>
| > > >>>>>>
| > > >>>>> congested
| > > >>>>>
| > > >>>>>
| > > >>>>>> AND
| > > >>>>>>     the probe packet contains the ROUTER ALERT option THEN
| > > >>>>>>     the probe packet can be distinguished from the other
| > > >>>>>>
| > > >>>>>>
| > > >>>>> PCN packets,
| > > >>>>>
| > > >>>>>
| > > >>>>>>     and therefore it will be for sure PCN_marking encoded.
| > > >>>>>>
| > > >>>>>>  ** if excess rate marking is used AND the 
| PCN-interior-node
| is
| > > >>>>>>
| > > >>>>>>
| > > >>>>> congested
| > > >>>>>
| > > >>>>>
| > > >>>>>> AND
| > > >>>>>>     the probe packet DOES NOT contain the ROUTER 
| ALERT option
| > > >>>>>>     THEN this MIGHT be PCN_marking encoded, or it MIGHT not
| be
| > > >>>>>> PCN_marking encoded. This depends
| > > >>>>>>     on whether this probe packet is selected to represent
| > > >>>>>>
| > > >>>>>>
| > > >>>>> the excess
| > > >>>>>
| > > >>>>>
| > > >>>>>> rate, or is not selected.
| > > >>>>>>
| > > >>>>>> Best regards,
| > > >>>>>> Georgios
| > > >>>>>>
| > > >>>>>>
| > > >>>>>>
| > > >>>>>>
| > > >>>>>>
| > > >>>>>>
| > > >>>>>>
| > > >>>>>>> -----Original Message-----
| > > >>>>>>> From: [email-masked] [mailto:[email-masked]]
| > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45
| > > >>>>>>> To: [email-masked]; [email-masked]
| > > >>>>>>> Cc: [email-masked]
| > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
| > > >>>>>>>
| > > >>>>>>> But why would the interior node *need* to distinguish it
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>> from other
| > > >>>>>
| > > >>>>>
| > > >>>>>>> pcn pkts?
| > > >>>>>>>
| > > >>>>>>> And even if you have got router alert, the architecture
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>> draft says:
| > > >>>>>
| > > >>>>>
| > > >>>>>>> "must be handled the same as (ordinary data) PCN-packets,
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>> in terms
| > > >>>>>
| > > >>>>>
| > > >>>>>>> of routing, scheduling and PCN-marking."
| > > >>>>>>> Even though your router alert's got it in slow path, will
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>> it handle
| > > >>>>>
| > > >>>>>
| > > >>>>>>> it any differently in terms of routing scehdulign &
| > > pcn-marking?
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>>>>
| > > >>>> _______________________________________________
| > > >>>> PCN mailing list
| > > >>>> [email-masked]
| > > >>>> https://www.ietf.org/mailman/listinfo/pcn
| > > >>>>
| > > >>>>
| > > >>> _______________________________________________
| > > >>> PCN mailing list
| > > >>> [email-masked]
| > > >>> https://www.ietf.org/mailman/listinfo/pcn
| > > >>>
| > > >>>
| > > >> --
| > > >> 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://www.ietf.org/mailman/listinfo/pcn
| > > >>
| > > >>
| > >
| > > --
| > > 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://www.ietf.org/mailman/listinfo/pcn
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 29 Feb 2008 09:29:18 +0100

Phil, 

regarding single codepoint marking, I don't see any other viable 
option if PCN is to be supported by MPLS backbones. What's 
your position on that?

Regards,

Rudiger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] 
| Sent: Wednesday, February 27, 2008 11:50 AM
| To: [email-masked]; [email-masked]
| Cc: [email-masked]
| Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| 
| Lars,
| Thanks for the detailed pointers on what we need to come to 
| consensus on. And the other detailed comments.
| Thanks for the follow-up Rudiger.
| 
| Summary:-
| 
| 1. I think we have consensus on the admission marking 
| behaviour, I'll send a separate email on this shortly.
| 
| 2. I think we have consensus on the termination marking 
| behaviour, I'll send a separate email on this shortly. 
| Assuming that Joe is convinced by Michael's EMFT i-d.
| 
| 3. in terms of edge behaviour for admission & termination, do 
| we need consensus on one solution? Since the Charter I 
| thought that the approach was that edge behaviour is in Info 
| docs and that there could be more than one edge behaviour 
| (but a single Std for interior behaviour). 
| Anyway, there are two approaches suggested for admission 
| (level of congestion & probing) and two for termination 
| (measuring rates and termination based on flow being marked). 
| I don't know how to reach consensus on doing one of each - 
| perhaps we could have consensus on which to do first??? 
| 
| 4. in terms of where the decision making functionality 
| resides, the ingress is probably more natural - since it 
| polices flows and understands any other flow requirements 
| that might impact the decision (such as relative importance). 
| As to what is signalled, I guess that partly depends on what 
| approach is being taken in point 3. 
| the centralised node is also possible for decision making, 
| but it's clearly understood that this is out of scope.
| 
| 5. you asked about single marking. I don't know if we have 
| consensus. My view is that the single marking approach isn't 
| accurate enough for admission control, except perhaps as a 
| migration step. allowing this possibility would require a bit 
| more complexity in the edge behaviour Info doc (extra 
| parameter configured same for all boundary nodes, tweak to 
| termination behaviour at edges).
| 
| A few follow-ups below (the rest I'll just work in).
| 
| Thanks
| phil
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of
| Lars
| > Eggert
| > Sent: 26 February 2008 17:00
| > To: ext Steven Blake
| > Cc: pcn
| > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
| > 
| > 
| > Section 1., paragraph 21:
| >  >    o  The PCN-domain extends to the end users.  The scenario is
| >  >       described in [I-D.babiarz-pcn-sip-cap].  A variant is that
| the
| >  >       PCN-domain extends out as far as the LAN edge switch.
| > 
| >    This deployment model may not be possible under the initial
| charter,
| >    or maybe even under an extended charter, because it is not clear
| that
| >    sufficient statistical multiplexing exists on the links near the
| edge
| >    to make PCN work, which is a *fundamental* assumption of PCN (see
| >    assumption 3 in Section 3). Listing this deployment 
| scenario here 
| > when
| >    we aren't sure how to support it raises false expectations - I'd 
| > hence
| >    propose to drop this bullet item.
| 
| Yes, it assumes that the links near the edge have sufficient 
| stat multiplexing. I'll move it to the Appendix, with a note 
| that if there is sufficient stat multiplexing then it's in scope. 
| 
| > Section 4.3., paragraph 4:
| >  >    A different possibility is to configure only the 
| PCN-lower-rate
| > and
| >  >    hence only do one type of PCN-marking, but generate admission
| and
| >  >    flow termination responses from different levels of marking.
| > This is
| >  >    suggested in [I-D.charny-pcn-single-marking] which 
| gives some of
| > the
| >  >    pros and cons of this approach.
| > 
| >    draft-charny is at odds with the second paragraph of the intro,
| which
| >    says that each link has a PCN-lower-rate and a PCN-upper-rate. If
| the
| >    intent of the architecture is to permit a proposal like
| draft-charny,
| >    those concepts need to be re-defined.
| > 
| 
| I'll try & clarify this. 
| I think S4.3. (Flow admission and flow termination) needs to 
| be clarified, and to clarify in Intro that PCN-domain doesn't 
| have to do admission & termination, but could just do one of them. 
| 
| 
| > 
| > 
| > Section 5.4., paragraph 8:
| >  >    The decision needs to be passed to the application 
| layer so that
| > it
| >  >    can take the appropriate action.
| > 
| >    The application layer at what node? And define "appropriate".
| 
| I think this sentence can be deleted, as it's already covered 
| by the earlier para in S5.4: "  o  Communicate decision about 
| admission "
| 
| > 
| > 
| > Section 5.6., paragraph 4:
| >  >    o  Use a probe packet that includes as payload the address of
| the
| >  >       PCN-ingress-node.
| > 
| >    I don't understand how a probe packet can be used by the 
| egress to
| >    determine the address of the ingress, if the egress 
| needs to know 
| > this
| >    address to send the probe packet. (But see my comment on probing 
| > below;
| >    this may be moot.)
| 
| "if the egress..."
| not sure I understand, it's the ingress that sends the probe 
| pkt. The idea was that when the ingress sends the probe, it 
| inserts into the pkt its address (ie the ingress address) - 
| which the egress then extracts when it gets the probe. 
| 
| > 
| > Section 7., paragraph 0:
| >  > 7.  Probing
| > 
| >    I am still opposed to probing as part of the PCN 
| architecture. It 
| > is a
| >    *very* complex mechanism with lots of open issues surrounding how
| it
| >    could actually be implemenented that in the end serves only one
| >    purpose: to slightly increase capacity utilization in a 
| PCN domain.
| >    However, PCN was never meant to remove the need for sufficient
| >    overprovisioning. A second reason is that probing is only really
| >    needed to extend PCN into scenarios where some of the assumptions
| >    (sufficient multiplexing, etc.) are no longer true. We 
| already have
| a
| >    boatload of explicitly-signalled QoS architectures that were
| designed
| >    for just such scenarios. I see no reason to complicate 
| PCN into yet
| >    another signalled-QoS system.
| > 
| >    We already had consensus in Vancouver to stop discussing probing 
| > until
| >    after work on the initial milestones has finished. I'd like to 
| > propose
| >    to remove the discussion of probing from the 
| architecture at least 
| > until
| >    that time.
| 
| I can move the Probing section to an Appendix. Of course I 
| could also delete it, although I guess there'll be objections to that.
| 
| > 
| > ------------------------------------------
| > 
| > NITS (only of interest to the authors)
| > 
| >    Nit: eliminate use of first person (throughout the document)
| >    Nit: s/ie/i.e.,/ (everywhere)
| >    Nit: s/eg/e.g.,/ (everywhere)
| 
| they can be spelt with or without the dots. I read somewhere 
| that without dots is the modern usage & have been a convert 
| ever since!
| 
| > 
| > Section 2., paragraph 1:
| >  >       nodes that perform DiffServ scheduling; the compete set of
| PCN-
| > 
| >    Nit: s/compete/complete/
| > 
| > Section 4.3., paragraph 2:
| >  >    sessions end, existing microflows naturally depart from the
| system
| > 
| >    Nit: s/microflow/flow/ (or else define what a microflow is; also
| >                            elsewhere in the document)
| 
| thanks, I managed to miss some. They mostly should be flow. 
| Where it means microflow I added ref to RFC2475 (eg in the 
| PCN-traffic definition in S2)
| 
| > 
| > _______________________________________________
| > PCN mailing list
| > [email-masked]
| > http://www.ietf.org/mailman/listinfo/pcn
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 29 Feb 2008 10:24:21 +0100

Hi Phil

Regarding the below comment!

> in terms of encoding, it does have a second encoding, but it 
> uses RAO bits rather than ECN/DSCP bits. 
> 
> identified) and about deploability barrier (will operators 
> deploy something that slows all their core routers - after 
> all we claimed one advantage of PCN over hop-by-hop rsvp is 
> that your core routers are really simple, don't have to do 
> any difficult processing...

In the architecture draft we mention that Intserv over Diffserv is one of
the scenarios that could be 
supported by PCN. In this case I assume that RSVP will be used as the
Intserv signaling protocol.
RSVP PATH carries already a Router Alert option.
The only additional functionality in the PCN-interior-nodes, is to use the
RAO bits for detection 
rather than an additional ECN/DSCP code.

Best regards,
Georgios

> Behalf Of [email-masked]
> Sent: donderdag 28 februari 2008 19:53
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> [1] single marking behaviour on interior routers [2] only 
> single encoding needed
> 
> your idea at first sight has just one marking behaviour, ie 
> excess rate marking. Indeed, it only has one token bucket. 
> However, it does have extra code/complexity in order to do 
> threshold marking for probe pkts, and this involves the pkt 
> being processed on the slow path within a router. I guess 
> this complexity is for pkt classification & PCN-encoding, 
> rather than for the PCN-metering function. 
> 
> in terms of encoding, it does have a second encoding, but it 
> uses RAO bits rather than ECN/DSCP bits. 
> 
> identified) and about deploability barrier (will operators 
> deploy something that slows all their core routers - after 
> all we claimed one advantage of PCN over hop-by-hop rsvp is 
> that your core routers are really simple, don't have to do 
> any difficult processing...
> 
> phil
> 
> Behalf Of
> > > probes, he wants to make sure that probe packets are always 
> > > AM-marked when a link is precongested with regard to the 
> admissible 
> > > introduces the problem of RAO.
> > > That impacts the forwarding of the packets as they need special 
> > > architecture draft said that all pcn packets should be treated in 
> > > the same way by PCN nodes which is no longer the case for normal 
> > > data packet and PCN packets.
> > >
> > > Regards,
> > >
> > >     Michael
> > >
> > > >>>>>>  ** if excess rate marking is used AND the 
> PCN-interior-node
> is
> > > >>>>>>
> > > >>>>>>
> > > >>>>> congested
> > > >>>>>
> > > >>>>>
> > > >>>>>> AND
> > > >>>>>>  ** if excess rate marking is used AND the 
> PCN-interior-node
> is
> > > >>>>>>
> > > >>>>>>
> > > >>>>> congested
> > > >>>>>
> > > >>>>>
> > > >>>>>> AND
> > > Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
> > > Germany, room B206

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 11:29:01 -0000

Whoah! The Intserv or diffserv model was always(*) about the rsvp hop
being edge to edge & no rsvp processing on the interior nodes. (*)ie
right back to the first architecture draft way before the PCN wg.

> Sent: 29 February 2008 09:24
> To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
> wuerzburg.de
> Cc: [email-masked]
multiple
> > > > >> itself but due to the use of excess rate marking for
admission
> > > > >> control.
> > > > >>>> termination state, but that due to the ECMP routing they
are
> > not
> > > > >>>> If an egress operates, for a certain
ingress-egress-agrregate
> > in
whether
> > > > >>>>>>     THEN this MIGHT be PCN_marking encoded, or it MIGHT
not
> > be

---

From: Steven Blake <[email-masked]>
Date: Fri, 29 Feb 2008 16:45:22 -0500

> Anyone know how routers deal with this?

This is very vendor-specific.

> NSIS' use of RAO, relying on RAO pretty much guarantees serious  

Agreed.

Regards,