Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-02.txt

From: [email-masked]
Date: Mon, 19 Nov 2007 10:20:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF.

	Title           : Pre-Congestion Notification Architecture
	Author(s)       : P. Eardley
	Filename        : draft-ietf-pcn-architecture-02.txt
	Pages           : 45
	Date            : 2007-11-19

The purpose of this document is to describe a general architecture
for flow admission and termination based on aggregated pre-congestion
information in order to protect the quality of service of established
inelastic flows within a single DiffServ domain.Status

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-pcn-architecture-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pcn-architecture-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 16:38:43 -0000

I updated the architecture draft with (I think) all the comments over
the last month. 

The main changes are:-
(1) the OAM section is extensively revised, thanks to Bob Briscoe. Could
another OAM person give this section a review please? (Tom T??)
(2) the probing section is extended. 

And a change to:-
(3) discussion & rule for 'partially PCN-capable tunnels' (S5.7)

On (2) I tried to capture all the recent discussion, hopefully fairly
successfully & not too controversially? Also, because it was getting
quite long I created a new section for all Probing text (S7). Personally
I wonder if this is now getting too long & with too much discussion (of
options and the circumstances when it might be a good idea or not) - so
I wonder if it should be removed to another draft. Joe, I remember you
saying you were (thinking of/) writing a new draft on probing, not sure
if it would fit with that [sorry not to ask you before, but I only
decided to write it at the weekend]

Other minor changes 
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-p
cn-architecture-02.txt&url2=http://tools.ietf.org/id/draft-ietf-pcn-arch
itecture-01.txt 

Best wishes,
Phil/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 19 November 2007 15:20
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-02.txt
>

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 08:18:46 -0000

This hasn't yet appeared on the ietf server, so here it is

> From: [email-masked] [mailto:[email-masked]]
> Sent: 19 November 2007 16:39
> To: [email-masked]
> Subject: RE: [PCN] I-D Action:draft-ietf-pcn-architecture-02.txt
> 
> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 20 Nov 2007 22:46:28 -0500

>decided to write it at the weekend]

[Joe]No Phil I did not write a draft of probing. However we added a
section into 3sm draft the uses on-path signalling (such as RSVP) as a
probe for admission control. I will review the new section in the
architecture draft on probing and send any comments to the list. 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: November 19, 2007 11:39 AM
To: [email-masked]
Subject: RE: [PCN] I-D Action:draft-ietf-pcn-architecture-02.txt

The main changes are:-

And a change to:-

Other minor changes 

Best wishes,
Phil/

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 22 Nov 2007 11:52:21 +0100

Phil,

the latest two versions of the architecture are 
indeed well written. Most of my comments on the 
chartered topics are editorial (with the 
exception of ingress policing). And that more 
discussion is useful on chartered topics is 
not surprising.

I've read the -01 version and checked that my 
comments still apply with -02. This is to say, 
that missing comments to the new -02 parts 
don't mean consent.

Regards,

Rudiger

-----comments-------------------------------

1. Introduction

Middle of second paragraph refers to "measurements"

"...PCN-egress-nodes make measurements of the 
 packet markings and send information..."

Next reference to "measurements" in 4th bullet point:

"The information of these measurements is signalled 
 to the PCN-egress-nodes by the PCN-marks in the 
 packet headers."

A first time reader my be puzzled by "these", as the 
last time measurements were explicity mentioned it 
were those of the egress and then "the egress sends"
while now something "is sent to the egress".

Proposal: 
"The congestion status of an interface marking 
PCN packets is signalled to the PCN-egress..."
------------------------------------------------------

First bullet point, last sentence

"It is not generally required that other network entities
 are aware of individual flows (although they may be in 
 particular deployment scenarios)."

A reference would be helpful to give the reader guidance 
on the particular deployment scenarios. If the above 
refers to signaling supported by all boundary nodes, 
"e.g. [I-D.briscoe-tsvwg-cl-architecture]" may be a good 
reference, if something else is meant, please 
refer to that something.
------------------------------------------------------

4th last bullet point

"The PCN-domain extends to the end users.  NOTE: This 
 isn't necessarily outside the Charter because it may 
 not break Assumption 3 (aggregation see later) if 
 it's known there's sufficient aggregation at any 
 bottleneck,......"

Could we add a bullet point on 

"Extending PCN-pre congestion feedback to the user 
 application. While this currently outside of the charter, 
 providing feedback of the PCN pre-congestion status 
 to user applications is a viable alternative to 
 termination, from a provider point of view as well 
 as from an end user point of view. Rate reduction 
 resulting from codec renegotiation is a typical 
 feature of real time applications optimised for a 
 connectionless Internet. Once load levels approach 
 the PCN-upper-rate, user applications may either be 
 informed by PCN packet marks carried with application 
 traffic (ECN or DSCP) or by signaling, if the 
 boundary node supports a per flow signaling protocol."

A sentence may be added to tell the reader, where this 
would be done (which is not clear to me, help is welcome).
----------------------------------------------------------

5.2.  PCN-ingress-node functions

"Packet classify" and "Policing" are only required at the 
PCN ingress, if no other trusted edge system is doing that.

If there's another edge system doing policing and 
classification, the PCN ingress node doesn't need 
to do this. The two bullet points may add:

"Note that packet classify/policing is only required by the 
PCN ingress node, if no other trusted upstream node operates 
these features."

Further, the section misses a statement on what the ingress 
node is supposed to do, if a PCN coloured packet is 
received on an interface where it is not supposed 
to be received (given the flow is admitted):
Ignore and remark or drop?
---------------------------------------------------------- 

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

7th bullet point

"Are there other ways of dealing with the flash crowd 
 scenario? .... or perhaps for a PCN-egress-node to block 
 new flows on its empty ingress-egress-aggregates when its 
 non-empty ones are pre-congested."

Should read
"...or for a PCN-boundary node to limit admission of new 
flows on its empty ingress-egress-aggregates..."

It should read boundary node, as the ingress receives 
pre-congestion feedback too and thus is aware of 
pre-congestion in the network.

Blocking is an extreme case of limiting admission and I 
don't think blocking is required in all cases. This topic 
clearly is for further study and we shouldn't limit 
solution space unless we have clear indications on 
these limits.
--------------------------------------------------------

10.  Security considerations

second bullet point

"the PCN-ingress-nodes police packets to ensure a flow 
 sticks within its agreed limit, and to ensure that only 
 flows which have been admitted contribute PCN-traffic 
 into the PCN-domain."

Respecting one of my earlier comments, this should read 
"the PCN-ingress-node or another trusted node controlling 
 access to PCN based transport"

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 11:19:30 -0000

Hi rudiger - in-line, thanks
phil

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 22 November 2007 10:52
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Subject: RE: [PCN] I-D Action:draft-ietf-pcn-architecture-01.txt
> 
> Phil,
> 
> exception of ingress policing). 

All Editorials - thanks will try to put into next version. 

> to do this. 

true. In the scenarios it says:
o  If the operator runs both the access network and the core network,
      one deployment scenario is that only the core network uses PCN
      admission control but per microflow policing is done at the
      ingress to the access network and not at the PCN-ingress-node.
      Note: to aid readability, the rest of this draft assumes that
      policing is done by the PCN-ingress-nodes.

However, I can add a small comment here & in section 10, as not
mentioning it is hindering rather than aiding readability!

> Ignore and remark or drop?

Good point. Can we just refer to some Diffserv text?

phil

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 22 Nov 2007 13:09:12 +0100

Hi Phil,

your suggestion is allright with me.

I found this sentence in RFC2475:

Ingress nodes must
   condition all other inbound traffic to ensure that the DS codepoints
   are acceptable; packets found to have unacceptable codepoints must
   either be discarded or must have their DS codepoints modified to
   acceptable values before being forwarded.

As PCN may also modify ECN codepoints, the staement must be extended to
cover these too. If only DSCPs are used, no traffic with "congestion 
experienced" marking must pass the ingress node unchanged.

Regards,

Rudiger

|All Editorials - thanks will try to put into next version. 
|
|> 
|> 5.2.  PCN-ingress-node functions
|> 
|> "Packet classify" and "Policing" are only required at the
|> PCN ingress, if no other trusted edge system is doing that.
|> 
|> If there's another edge system doing policing and
|> classification, the PCN ingress node doesn't need
|> to do this. 
|
|true. In the scenarios it says:
|o  If the operator runs both the access network and the core network,
|      one deployment scenario is that only the core network uses PCN
|      admission control but per microflow policing is done at the
|      ingress to the access network and not at the PCN-ingress-node.
|      Note: to aid readability, the rest of this draft assumes that
|      policing is done by the PCN-ingress-nodes.
|
|However, I can add a small comment here & in section 10, as not
|mentioning it is hindering rather than aiding readability!
|
|> 
|> "Note that packet classify/policing is only required by the
|> PCN ingress node, if no other trusted upstream node operates
|> these features."
|> 
|> Further, the section misses a statement on what the ingress
|> node is supposed to do, if a PCN coloured packet is
|> received on an interface where it is not supposed
|> to be received (given the flow is admitted):
|> Ignore and remark or drop?
|
|Good point. Can we just refer to some Diffserv text?
|
|phil
|
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 23 Nov 2007 10:58:52 +0100

Hi Phil,

I've read the chapters on ECMP, probing and OAM. I'm 
not an expert on the latter however. Your text captures 
most of the discussion. I however think, it is to 
coarse in leading to a decision whether to probe or 
not to. My comments center around this issue.

Regards,

Rudiger

----------hereWeGo------------------------------------

6.  Design goals and challenges

7th bullet point

"ECMP and signalling: It is possible that, in a PCN-domain
 running ECMP, the signalling packets (eg RSVP, NSIS) 
 follow a different path than the data packets - it depends
 on which fields the ECMP algorithm uses.  This could matter
 if the signalling packets are used as probes."

We can be more specific on this one, I think:

"ECMP and signalling: If the ECMP hashing algorithm applied 
 by the routers of a PCN domain is based on more than just 
 the IP addresses of a packet, is possible that the 
 signalling packets (eg RSVP, NSIS) follow a different path 
 than the data packets. If the ECMP hashing algorithm can be 
 restricted to a packets IP adresses, per flow RSVP and NSIS 
 signaling messages may be transmitted coloured as PCN 
 traffic. They will then pass the same links as the data 
 packets and hence allow identification of flows requesting 
 admission on links approaching the upper PCN rate 
 (independent of the marking algorithm)."

The statement expresses the minimum solution we can offer 
to deal with the problem. I prefer this to leaving the reader
with "this could matter".
-----------------------------------------------------------

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

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

My general take on the probing disussion: Leave the 
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.