Subject: Re: [PCN] draft-ietf-pcn-architecture-05

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 11 Aug 2008 13:57:10 +0200

Hi

I have read through the document and I find the draft quite comprehensible even for a person that is relatively close to laymans level and I believe that many of the concepts that I did not understand how they should work a few months ago has been clarified, atleast on a higher level.

Some comments/nits.

Secion 6. High-level functional architecture
"The objective is to standardise PCN-
 marking behaviour, but potentially produce more than one
 (informational) RFC describing how PCN-boundary-nodes react to PCN-
 marks."
Find the sentence a bit odd, should it be something like "but may potentially produce" ?

Section 6.6. Backwards compatibility
My impression is that the 2nd last paragraph (to block ECN-capable traffic) is mostly applicable to pcn base line encoding. With the use of tunneling or a future pcn encoding (e.g 3-state) this requirement is more relaxed. Am I right. If this is the case I would suggest that the text makes this more clear.

Section 7.2. PCN-ingress-node functions
Second bullet ends with "If PCN", text missing ?

Section 8. Design goals and challenges
"Flash crowds and Speed of Reaction". Even though it is currently maybe outside the WG charter, e2e ECN is one way to limit the potential harm caused by flash crowds, this mechanism and how it is supposed to interact with PCN needs more study though.

Regards
Ingemar

******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)8 4043042 
ECN: 850-43042 
ECC: 850-43074 
Mobile: +46 (0)730 783289 
******************************************* 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Tue, 12 Aug 2008 10:54:41 +0100

Thanks for the support, and the comments
In-line
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Ingemar Johansson S
{ Sent: 11 August 2008 12:57
{ To: [email-masked]
{ Subject: Re: [PCN] draft-ietf-pcn-architecture-05
{ 
{ Hi
{ 
{ I have read through the document and I find the draft quite comprehensible
{ even for a person that is relatively close to laymans level and I believe
{ that many of the concepts that I did not understand how they should work a
{ few months ago has been clarified, atleast on a higher level.
{ 
{ Some comments/nits.
{ 
{ Secion 6. High-level functional architecture
{ "The objective is to standardise PCN-
{  marking behaviour, but potentially produce more than one
{  (informational) RFC describing how PCN-boundary-nodes react to PCN-
{  marks."
{ Find the sentence a bit odd, should it be something like "but may
{ potentially produce" ?

will re-phrase
{ 
{ Section 6.6. Backwards compatibility
{ My impression is that the 2nd last paragraph (to block ECN-capable
{ traffic) is mostly applicable to pcn base line encoding. With the use of
{ tunneling or a future pcn encoding (e.g 3-state) this requirement is more
{ relaxed. Am I right. If this is the case I would suggest that the text
{ makes this more clear.

Yes you're right, the 2nd last para is about pcn baseline encoding. And yes, extended encoding might do something different. Will try to clarify. 

{ 
{ Section 7.2. PCN-ingress-node functions
{ Second bullet ends with "If PCN", text missing ?

"If PCN" should be deleted. 

{ 
{ Section 8. Design goals and challenges
{ "Flash crowds and Speed of Reaction". Even though it is currently maybe
{ outside the WG charter, e2e ECN is one way to limit the potential harm
{ caused by flash crowds, this mechanism and how it is supposed to interact
{ with PCN needs more study though.

Possibly, I'm not sure. Anyway, in this section I tried to avoid talking about solutions at all, only problems. (there's a note to say this at the start of the long list of bullets of potential issues.) This was partly for reasons of space, and partly because I thought it would be inappropriate to say "here are 4 potential solutions to the problem, but we're not going to say anything (or anything definitive) about which one to choose".
Anyway, at the moment I won't change any text here (please follow-up if you want).

{ 
{ 
{ Regards
{ Ingemar
{ 
{ *******************************************
{ Ingemar Johansson
{ Senior Research Engineer, IETF "nethead"
{ EAB/TVP - Multimedia Technologies
{ Ericsson Research Ericsson AB
{ Box 920 S-971 28 Luleå, Sweden
{ Tel: +46 (0)8 4043042
{ ECN: 850-43042
{ ECC: 850-43074
{ Mobile: +46 (0)730 783289
{ *******************************************
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn