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

From: [email-masked]
Date: Wed, 02 Mar 2011 03:30:02 -0800

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           : Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain
	Author(s)       : G. Karagiannis, et al.
	Filename        : draft-ietf-pcn-signaling-requirements-02.txt
	Pages           : 11
	Date            : 2011-03-02

Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain. The 
overall PCN architecture is described in RFC 5559. This memo 
describes the requirements for the signaling applied within the PCN 
domain: (1) PCN feedback is carried from the PCN-egress-node to the 
decision point;(2) the decision point may demand for the measurement 
and delivery of the PCN rate sent at the PCN-ingress-node. The 
decision point may be either collocated with the PCN-ingress-node or 
a centralized node.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 2 Mar 2011 13:11:57 +0100

Hi Phil, Hi all

The 02 version of the PCN signaling requirements draft has just been
uploaded on the IETF registry, see:

http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-02
.txt

I have worked out all the comments provided by Phil, see below, and updated
the PCN signaling requirements draft accordingly!

In line I am providing some observations on the comments provided by Phil!

If you have any comments please let me know?

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: dinsdag 26 oktober 2010 12:14
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] WGLC for 
> draft-ietf-pcn-signaling-requirements-01.txt?
> 
> Unfortunately the doc seems to need a lot of work to me. 
> 
> *	It repeats a lot of the edge behaviour docs. If i get 
> it right, this doc is supposed to be *just* about the 
> signalling (the requirements for signalling) - the edge node 
> behaviour docs talk about the *content* that is signalled. To 
> take just one example:

Georgios: the above comment is worked out!

> o	S2.2 starts by listing what the PCN-egress-node 
> measures - but this doc should be about reports - reporting 
> the info that's been measured (reference edge behaviour doc 
> for details of what is measured)
> o	The list anyway doesn't match the edge behaviour docs 
> (CLE may or may not be calculated by PCN-egress-node)
> *	There are some new security considerations that i don't 
> agree with. See below. 

Georgios: the above comment is worked out!

> *	The terminology should consistently re-use what has 
> already been defined in our RFCs and what is defined in the 
> edge behaviour docs. See below. 

Georgios: the above comment is worked out!

> *	The sub-section headings of S2 & S3 should match. This 
> might help S3 to be re-written more clearly. 

Georgios: Now The sub-section headings of S2 & S3 match!

> *	S3.3 is untrue. 3.2 & 2.3.6 are different [at least] 

Georgios: this is corrected!

> *	S2.2: I don't think report suppression should be 
> mentioned here as a compulsory feature. This is to do with 
> specific signalling examples (CL, SM) and not a general 
> feature required of all imaginable PCN edge signalling. 
> Report suppression is a feature of the edge behaviour. At 
> most this doc should say something like "A report may either 
> be sent periodically, every time the PCN-egress-node measures 
> the various rates, or else may be sent occasionally (see 
> "optional report suppression", for instance in [ref])

Georgios: Done!

> *	S2.2, concatenating the flow Ids raises too many issues 
> on format, order, what a flow ID is etc. Delete

Georgios: Done!

> *	The phrasing needs to be better in several places, eg 
> the abstract, the latter part of para 1 & para 2 of Intro. 

Georgios: Tried to fix this!

> *	Also S2.3.3 "The signaling protocol MUST be able to 
> carry identification (address information) of the PCN edge 
> nodes." -> "The signaling protocol MUST carry the identity of 
> the PCN-egress-node that sends the message." The rest of the 
> section can be deleted. Similar comment about 2.3.4. S2.3.5 
> can be shortened to "The load generated by the signaling 
> protocol SHOULD be minimized.". 

Georgios: Done!

> *	S3 is hard to understand. It can be much shorter; 
> similar to S2 it should be confined to signalling; something 
> like "Request - response signalling is used" would clarify it. 

Georgios: Tried to fix this!

> *	S2.1 title - delete "PCN". Delete last sentence 
> [nothing to do with the sub-section]

Georgios: Done!

> *	S2.2, title, delete "Signalled"

Georgios: Done!

> *	S2.4 something here needs to be capitalised.

Georgios: PCN-ingress-node and PCN-egress-node used instead of ingress and
egress, respectively.
 
> 
> Question: S1, para 2, here and elsewhere you say the 
> signalling is "towards" the decision point. Why don't you say 
> "to" the decision point?  Is this because you're thinking the 
> msg could piggy-back on some existing signalling (like rsvp)? 
> If yes, i think it would be better to spell this out specifically:
> <<Signaling needs to transport:
> *	PCN egress feedback, from a PCN-egress-node to the 
> decision point
> *	A request, from the decision point to a 
> PCN-ingress-node, that triggers the PCN-ingress-node to 
> measure the PCN-sent-rate
> *	PCN ingress feedback, from a PCN-ingress-node to the 
> decision point. 
> A signalling message may either be sent directly, or may 
> piggy-back on some other message that is being sent via the 
> relevant node.>>

Georgios: Done!

> 
> Security
> I don't see why msg authentication & integrity, anti-DOS 
> measures are a SHOULD. The base assumption of PCN 
> architecture is that PCN operates within a trusted domain, ie 
> all nodes in the domain are trusted. So it's ok providing the 
> msg comes from an interface internal to the PCN-domain.
> I don't understand the msg confidentiality bullet. When would 
> PCN signalling msgs be visible to non-autorsied nodes; and if 
> there is such a case, where is msg confidentiality only a 
> MAY? The reqt surely is that msgs don't leak out of the 
> PCN-domain - which should be easy since msgs are sent to the 
> PCN-boundary-node's address
> 
> Replace S2.3.7 with something like the following:- The PCN 
> architecture [ref] assumes that all PCN-nodes are PCN-enabled 
> and trusted to operate correctly. In the context of this document:
> * PCN-signalling messages MUST NOT leak out of the PCN-domain (+)
> * PCN-boundary-nodes MUST validate the signalling messages, 
> to avoid that they come from an attacker (*)
> (+) should be easy, since msgs are sent to the 
> PCN-boundary-node's address
> (*) one way is simply: does the msg arrive on an interface 
> internal to the PCN-domain? If yes, it isn't from an 
> attacker, since all PCN-nodes are trusted

Georgios: Done!

> 
> Terminology
> *	consistently use terminology from 5559: PCN-traffic, 
> PCN-ingress-node, PCN-egress-node ETC etc

Georgios: Done!

> *	use terminology from the edge behaviour docs - 
> PCN-sent-rate, NM-rate, ETM-rate, THM-rate, CLE could all be 
> re-used (and CLE is badly defined here)

Georgios: Done!

> *	decision point, delete "of course"

Georgios: Done!

> *	PCN egress feedback - definition could be better. I 
> think the "feedback" is the report (not the "content") "A 
> report sent by the PCN-egress-node to the decision point; it 
> reports measurements made by the PCN-egress-node that inform 
> decisions about flow admission and flow termination"

Georgios: Done!

> *	PCN ingress feedback - similar. Also, does the report 
> ever include anything other than PCN-sent-rate?
> *	"A report sent by the PCN-ingress-node to the decision 
> point; it reports measurements(*) made by the 
> PCN-ingress-node that inform decisions about flow 
> termination"  (*) or "the measurement of PCN-sent-rate"

Georgios: Done!

> *	I'd delete "Ingress rate request". It's easy to refer 
> to this as a request for PCN ingress feedback

Georgios: Done!

Best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Sat, 19 Mar 2011 11:16:24 +0100

Hi Georgios, hi all,

I went through the draft twice. I realized many redundancies and 
inaccuracies. I tried to streamline and shorten the document to remove 
these shortcomings so that the actual contents of the draft is more 
visible. You find my modifications and comments attached to the email. I 
did not change technical contents, at least not intentionally. I find 
that the doc needs some more clarifications at some points. Please see 
inline!

Best wishes,

     Michael

Am 02.03.2011 13:11, schrieb Georgios Karagiannis:
>> *	The sub-section headings of S2&  S3 should match. This
> Georgios: Now The sub-section headings of S2&  S3 match!
>
>
>> *	S3.3 is untrue. 3.2&  2.3.6 are different [at least]
>> the abstract, the latter part of para 1&  para 2 of Intro.
>> I don't see why msg authentication&  integrity, anti-DOS
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 19 Mar 2011 11:50:27 +0000

Hi Michael

Thanks for your comments!
Please note that some of the comments/changes that you give/propose are
opossite to the ones given/proposed by Phil, which I have used to update
the draft, see email below.

Please check Phils comments and express your observations on these
comments. Please use the below email to provide your
agreement/disagreement with the comments of Phil and the way of how I
worked them out.

After this step we could discuss the rest of your provided comments!

Best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Sat, 19 Mar 2011 21:48:05 +0100

Hi Georgios,

> After this step we could discuss the rest of your provided comments!
I've checked Phil's comments and found them mostly in line with what I 
have changed in my revision. I added now NM-rate, ThM-rate, and ETM-rate 
as those terms are defined in the edge behavior drafts.

Best wishes,

      Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 22 Mar 2011 22:44:13 +0000

Hi Phil, Hi Michael

Phil, some of the comments provided by Michael on the 02 version of the
signaling requirement draft are opposite to the ones that you provided
on the previous version of the signaling requirements draft.

I have the feeling that if I accept the comments provided by Michael then
the 03 version (next version) of the signaling requirements draft will
be almost identical to the 01 version of the draft that Phil have
commented on.

Therefore, I would very much appreciate if Phil and Michael will have a
consensus on their comments before I can use them to update the
signaling requirements draft.

Best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 07:50:39 +0100

Hi Georgios,

Am 22.03.2011 23:44, schrieb Georgios Karagiannis:
> be almost identical to the 01 version of the draft
Definitely not! My concern was rather readability than technical issues: 
remove redundancy, enforce consistency, kick out what has no content!

Michael

> that Phil have

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 23 Mar 2011 06:57:30 +0000

Hi Michael

Okay, if Phil agrees with your comments then I will use your suggestions.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 09:34:29 +0000

Will review before the PCN meeting.

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 23 March 2011 06:58
To: Michael Menth
Cc: Eardley,PL,Philip,DES8 R; [email-masked]
Subject: Re: opposite comments on signaling requirements draft

Hi Michael

Best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 10:49:58 +0100

Hi Phil,

I just tried to clean up the doc, my intent was not to change any 
content. If you think something is wrong or missing, please change or 
add it! Maybe it is the easiest if you take the Word doc I sent to the 
list and add your changes / comments right there?

Michael

Am 23.03.2011 10:34, schrieb [email-masked]:
> On 3/23/2011, "Michael Menth"<[email-masked]>  wrote:
>
>> Hi Georgios,
>>

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 09:55:46 +0000

Ok. If i remember right, most of my comments were editorial rather than technical - substantial editorial comments.

Is the latest version the email 21st 16:48?

(Out of interest, aren't updates being done in xml?)

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 23 March 2011 09:50
To: Eardley,PL,Philip,DES8 R
Cc: [email-masked]; [email-masked]
Subject: Re: opposite comments on signaling requirements draft

Hi Phil,

Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Mar 2011 11:01:30 +0100

Hi Phil,

> Is the latest version the email 21st 16:48?
I sent my comments in form of a word/pdf file on 19th. I attach that 
email to avoid confusion.

Best wishes,

     Michael

Subject: Re: [PCN] Submitted draft-ietf-pcn-signaling-requirements-02.txt
From: Michael Menth <[email-masked]>
To: Georgios Karagiannis <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Sat, 19 Mar 2011 21:48:05 +0100

Hi Georgios,

Best wishes,

      Michael