Subject: [PCN] Questions on probing

From: Steven Blake <[email-masked]>
Date: Tue, 11 Dec 2007 13:26:55 -0500

During last week's meeting there was some discussion regarding the role
of probing in PCN (see the preliminary minutes):

1. Does there need to be any discussion of probing in the architecture
   draft?

2. If yes to (1), is the current text in the architecture draft
   essentially correct and sufficient?

3. Does the working group need to do protocol work on probing prior to
   last call for the architecture draft?

By the judgement of the chairs, the consensus of the room for each
question was 1 - Yes, 2 - Yes, 3 - No (and these weren't close calls).

We are opening these questions for discussion on the list.  Please
review the architecture draft -02 (especially Sec. 7) and send your
feedback to the list.

Regards,

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

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 12 Dec 2007 08:57:02 +0100

Steve,

generally I share the view of the room. I think the text in the
architecture-02 is still focused to much on an expectation that probing
is a regular requirement. I've commented on that earlier and attach my
comments again below.

If agreement is to progress the architecture without further discussion
on probing, I can accept that.

Regards,

Rudiger

Comments in line.

|During last week's meeting there was some discussion regarding the role
|of probing in PCN (see the preliminary minutes):
|
|1. Does there need to be any discussion of probing in the architecture
|   draft?

Yes.

|2. If yes to (1), is the current text in the architecture draft
|   essentially correct and sufficient?

My general take on the probing disussion: Leave just section '7.1 
Introduction' in the architecture and refer to another document 
for a detailed discussion. Alternatively, move 7.2 and 7.3 to 
the annex of the architecture doc.

|3. Does the working group need to do protocol work on probing prior to
|   last call for the architecture draft?

No.

Detailed comments:

7.1.  Introduction (to probing)

2nd paragraph, last sentence

"This risk could be lessened by configuring on each link 
 sufficient 'safety margin' above the PCN-lower-rate."

Please add:

"Further, the decision could be based on whether any of 
 the boundary nodes involved in admission of the new flow
 on the unused aggregate is aware of pre-congestion for
 any of his already admitted aggregates. If there is no 
 pre-congestion, the flow can be admitted with little 
 risk. "

I prefer to be explicit here, as I don't think the options 
are just "being optimistic" or "probing".
------------------------------------------------------------

3rd paragraph

"The PCN-ingress-node explicitly determines, before admitting
 the prospective new flow, whether the ingress-egress-
 aggregate can support it."

I'd suggest to add:

"If necessary, the PCN-ingress-node...."

I don't completely object to probing as long as I'm not sure 
that all options avoiding it have been explored. I'd like to
make sure that it is a "last resort". That's why I prefer to
have the statements on probing to be less "binary", just 
leaving you with an on/off decision. 
-------------------------------------------------------------

7.2.  Probing functions

Please change first bullet point to:

" Make decision that probing is needed.  As described above, 
  this is when the ingress-egress-aggregate or the ECMP path 
  is likely to carry no PCN-traffic."
  ^^^^^^^^^^^^^^^^^^
--------------------------------------------------------------

2nd bullet point

Please change to:

" (if required) Communicate the request that probing is needed
  - the PCN-egress-node signals to the PCN-ingress-node that 
  probing is needed (or the other way around).
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
The ingress could also indicate that probing is required and 
will start to the egress.
--------------------------------------------------------------

7.3.  Discussion of rationale for probing, its downsides 
      and open issues

I don't agree to the negative statement on the PCN coloured 
signaling messages (mentioned in third viewpoint). Given that
an ECMP algorithm is limited to evaluate addresses, PCN 
coloured per flow signaling messages are good means to avoid 
unnecessary termination of admitted flows. The signalling 
packet is received with a congestion mark, and the new flow 
is blocked. This method solves downside issues of the other 
two viewpoints - it is just a single packet transmitted via 
a link approaching the upper rate. So it is unlikly that it 
causes admitted flows to be terminated.
Note that I don't regard this as probing, as the signaling 
message is transmitted anyway.
---------------------------------------------------------------

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 12 Dec 2007 11:21:38 +0100

Hi Steven, Hi all

Regarding the questions sent you can fing my answers below.

* Regarding question (1), Yes, I think it is needed to have a discussion of
probing in the architecture draft.

* Regarding queestion (2), Yes and No. The current text is correct up to a
certain point.
Below I resend the comment that I have sent some time ago on the PCN list:

In Section 7.3, page 29, you provide the below conclusion on the viewpoint
that admission control is always done by probing:

"The first point breaks Assumption 3 (aggregation) and hence means that this
viewpoint is out of scope of initial Charter of the PCN WG."

I do not agree with this conclusion, since I do not agree with the
argumentation that the first point breaks Assumption 3 more than the
situation that no probing is used during admission control.
Therefore, please remove the sentence:
"The first point breaks Assumption 3 (aggregation) and hence means that this
viewpoint is out of scope of initial Charter of the PCN WG." 

* Regarding question (3), No, I do not think that working group need to do
protocol work on probing prior to
last call for the architecture draft?

Best regards,
Georgios

> -----Original Message-----
> From: Steven Blake [mailto:[email-masked]] 
> Sent: dinsdag 11 december 2007 19:27
> To: pcn
> Subject: [PCN] Questions on probing
> 
> During last week's meeting there was some discussion 
> regarding the role of probing in PCN (see the preliminary minutes):
> 
> By the judgement of the chairs, the consensus of the room for 
> each question was 1 - Yes, 2 - Yes, 3 - No (and these weren't 
> close calls).
> 
> We are opening these questions for discussion on the list.  
> Please review the architecture draft -02 (especially Sec. 7) 
> and send your feedback to the list.
> 
> 
> Regards,
> 
> Scott & Steve
>

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 12:34:18 -0000

Hi Georgios
To pick up on our of your comments, which concerns the archit draft

> 
> "The first point breaks Assumption 3 (aggregation) and hence means
that
> this
> "The first point breaks Assumption 3 (aggregation) and hence means
that
> this

I don't understand your comment, and wonder if it's just that the
section is not very clear about the context of the draft at this point. 

the third viewpoint on 'why do probing' is simply 'admission control is
always done by probing'.  It assumes the following:

   o  Simply admitting the new flow has a significant risk of leading to
      overload, because the PCN-domain reaches out towards the end
      terminals where link capacity is low.

   o  Every admission control decision involves probing, using the
      signalling set-up message as the probe packet (eg RSVP PATH).

   o  The PCN-marking behaviour is such that every packet is PCN-marked
      if the flow should be blocked, hence only a single probing packet
      is needed.

   I think the first of these bullets breaks Assumption 3 (aggregation)
and hence means that this viewpoint is out of scope of the initial
Charter of the PCN WG.

phil

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 12:56:06 -0000

Rudiger

Thanks, will work through the detailed comments when I do the next rev,
and also think about your suggestion of moving some of the text to an
annex.

phil

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 12 December 2007 07:57
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] Questions on probing
> 
> Steve,
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Dec 2007 15:33:58 +0100

Hi Phil

My point is that I do not agree that the below bullet 
breaks Assumption 3 (aggregation). This depends on how the algorithm is 
implemented and I thought that the architectural draft should not describe
implementation steps. 

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 13 december 2007 13:34
> To: [email-masked]; [email-masked]; [email-masked]
> I don't understand your comment, and wonder if it's just that 
> the section is not very clear about the context of the draft 
> at this point. 
> 
> the third viewpoint on 'why do probing' is simply 'admission 
> control is always done by probing'.  It assumes the following:
> 
>    I think the first of these bullets breaks Assumption 3 
> (aggregation) and hence means that this viewpoint is out of 
> scope of the initial Charter of the PCN WG.
> 
> phil
>

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 14:46:03 -0000

I don't see why this depends on implementation. Surely it depends on the
scenario. The scenario I was thinking of was where the PCN-domain
reaches out towards the end terminals where link capacity is low. (Well
that could be better written - it's possible that there might be high
link capacity near the end terminals, but normally link cap is lower
near the edge.)
Low link cap, in general, breaks the aggregation assumption.

Now there're some people who have in mind using PCN in such scenarios,
and doing adm ctrl by probing (for all new flows). The text does not
make any judgement about whether such an approach is feasible, merely
that it's out of the current scope.

phil

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 13 December 2007 14:34
> To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Dec 2007 17:06:45 +0100

Hi Phil

Sorry, but reading the text in Section 7.3 it gives me the impression that 
the architecture draft is trying to get out of the PCN scope the feature
that provides
admission control when probing is used.

The given argumentation on the aggregation issue is in my opinion only valid
for some 
implementations/scenarios and cannot be extrapolated to cover all possible
scenarios/implementations 
that are covered by the PCN scope.

Best regards,
Georgios

> Sent: donderdag 13 december 2007 15:46
> I don't see why this depends on implementation. Surely it 
> depends on the scenario. The scenario I was thinking of was 
> where the PCN-domain reaches out towards the end terminals 
> where link capacity is low. (Well that could be better 
> written - it's possible that there might be high link 
> capacity near the end terminals, but normally link cap is 
> lower near the edge.) Low link cap, in general, breaks the 
> aggregation assumption.
> 
> Now there're some people who have in mind using PCN in such 
> scenarios, and doing adm ctrl by probing (for all new flows). 
> The text does not make any judgement about whether such an 
> approach is feasible, merely that it's out of the current scope.
> 
> phil
> 
> > My point is that I do not agree that the below bullet breaks 
> > Assumption 3 (aggregation). This depends on how the algorithm
> is
> > > the third viewpoint on 'why do probing' is simply 
> 'admission control 
> > > is always done by probing'.  It assumes the following:
> > >
> > > (aggregation) and hence means that this viewpoint is out 
> of scope of 
> > > the initial Charter of the PCN WG.
> > >
> > > phil
> > >
> > 
>

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 16:44:36 -0000

Great, we're in violent agreement that I need to clarify this!

> Sent: 13 December 2007 16:07
> > > > o  Simply admitting the new flow has a significant risk of
leading
> > to
the

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 14 Dec 2007 11:22:39 +0100

Hi Phil

Great! Thank you very much!

Best regards,
Georgios

> Sent: donderdag 13 december 2007 17:45
> > Sorry, but reading the text in Section 7.3 it gives me the 
> impression
> that
> > The given argumentation on the aggregation issue is in my 
> opinion only 
> > valid for some implementations/scenarios and cannot be 
> extrapolated to 
> > cover all
> possible
> depends on 
> > > the scenario. The scenario I was thinking of was where the 
> > > PCN-domain reaches out towards the end terminals where 
> link capacity 
> > > is low. (Well that could be better written - it's possible that 
> > > there might be high link capacity near the end terminals, but 
> > > normally link cap is lower near the edge.) Low link cap, 
> in general, 
> > > breaks the aggregation assumption.
> > >
> > > The text does not make any judgement about whether such 
> an approach 
> > > is feasible, merely that it's out of the current scope.
> > >
> > > phil
> > >
> > > > implemented and I thought that the architectural draft 
> should not
> > > describe
> > > > implementation steps.
> > > >
> > > > > section is not very clear about the context of the 
> draft at this 
> > > > > point.
> > > > >
> > > > > leading to
> > > > >       if the flow should be blocked, hence only a 
> single probing 
> > > > > packet
> > > > >       is needed.
> > > > >