Subject: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 12 May 2009 10:36:00 +0200

Hi

I have some comments on draft-ietf-pcn-marking-behaviour-03. I would believe that all the comments are of the nit-picking kind also it has been a few moons since I had time to delve into this area and I may have missed something so I trust you to disagree where needed :-)

Section 1, bullet 1 : "its objective is to mark all packets...". 
Is it necessary to have "all" in the sentence ?. 
As I see it it is likely that a token bucket will introduce a threshold marking pattern that is not a continuous threshold-mark for all packets, this mecause the bucket level may be either above or below the threshold when a packet arrives. The word "all" in the sentence gives me that all packets within some given time frame are marked and my understand that this is not the case (I believe). But perhaps I am over-interpreting the statement ?. 

Section 2.4, bullet 1 : Is it possible to make a reference to the motivation behind this in B.6 ?

Section 2.4, MTU : As a reader I get a bit confused here. My (application view) interpretation of MTU is the maximum allowed packet size that is discovered by an endpoint (is this refered to as path-MTU ?). In this context however I believe it is the maximum experienced packet size on the link. 

Section B.1, Competing-non-PCN-traffic: "In such cases PCN-traffic and competing-non-PCN-traffic are distinguished by different values of the ECN field [I-D.ietf-pcn-baseline-encoding]"
  I would suggest that the sentence is slightly rewritten as
"In such cases, and if baseline encoding [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and competing-non-PCN-traffic are distinguished by different values of the ECN field" 
The reason is that it may not be possible to do this distinction with other encoding schemas.

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)10 7143042 
ECN: 852-43042 
ECC: 852-19042
Mobile: +46 (0)730 783289 
Visit http://labs.ericsson.com !
*******************************************

---

From: Michael Menth <[email-masked]>
Date: Tue, 12 May 2009 16:06:47 +0200

Hi Ingemar, hi Phil,

> Section 2.4, MTU : As a reader I get a bit confused here. My (application view) interpretation of MTU is the maximum allowed packet size that is discovered by an endpoint (is this refered to as pat…
Phil, packet-size-independent marking can be achieved for excess marking 
simply by letting the token bucket counter become negative. When the 
counter is larger than zero, the packet is not marked, otherwise it is 
marked. This eliminates unclarities about MTUs and simplifies configuration.

> The reason is that it may not be possible to do this distinction with other encoding schemas.
I believe that any encoding for PCN traffic needs to make sure that PCN 
traffic can be differentiated from non-PCN traffic. I do not think that 
we need to make this statement depending on any encoding scheme.

Regards,

    Michael

> _______________________________________________
> 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/31-86644 (new), fax: (+49)-931/8888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Wed, 13 May 2009 16:57:37 +0100

ingemar,
i dont seem to have got your email, so sorry for what i dont answer!

________________________________

From: [email-masked] on behalf of Michael Menth
Sent: Tue 12/05/2009 15:06
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, some comments

Hi Ingemar, hi Phil,

> As I see it it is likely that a token bucket will introduce a threshold marking pattern that is not a continuous threshold-mark for all packets, this mecause the bucket level may be either above or…

[phil] correct, it doesnt latch into a state where every pkt is marked for N secs regardless of the state of the token bucket. i think by "all" it was trying to contrast with the excess marking, where some pkts are always unmarked (up to the excess-traffic-rate). hopefully when it gets to teh formal description of the metering behaviour this is clear, i'll look how to improve the Intro text (maybe just deleting 'all' is enough]

> Section 2.4, bullet 1 : Is it possible to make a reference to the motivation behind this in B.6 ?

[phil] - it is! para 4, "This avoids over-
   termination (with some edge behaviours) in the event that the PCN-
   traffic passes through multiple bottlenecks in the PCN-domain
   [I-D.charny-pcn-comparison <https://mail.bt.com/exchange/EARDLEPL/Drafts/RE:%20%5BPCN%5D%20draft-ietf-pcn-marking-behaviour-03.txt,%20some%20comments.EML/1_text.htm#ref-I-D.charny-pcn-comparison> ].  "

[phil] ingemar, you're right. i'll get rid of the MTU term which is adding only unclearness. 

[phil] michael, true, that seems to be a way of implementing it (btw what do you do if another pkt arrives whilst TB is negative? - dont think paper mentions this). i'm not sure it's the best way here, which is description to make clear the objective /behaviour of the metering, without implying a particualr implementation. 

[phil] ingemar, this really comes out of the disussions about encoding, and how baseline & future extensions relate to each other - and as michael says, way of distinguishing pcn & competing-non-pcn traffic in way that doesnt depend on the coding scheme. anyway, to shift the discussion onto the encoding draft! - i just copied what the baseline encoding says. It defines (S5) "Rules for Experimental Encoding Schemes":

   o  The 00 codepoint in the ECN field SHALL indicate not-PCN and MUST
      NOT be changed to any otehr codepoint within a PCN-domain.
      Therefore an ingress node wishing to disable PCN marking for a
      packet within a PCN-compatible DiffServ Codepoint MUST set the ECN
      field to 00.
 i guess your idea is that with some exptal encoding (you have in mind?) the pcn & competing-non-pcn traffic might be differentiated by something other than the ecn field? (maybe dscp??) perhaps some other verb than "are distinguished" would be better (which perhaps implies a method ratehr than a potential method?) (maybe re-phrase as: "they differ in their values of the ECN field"?). sory if i don't get your point proprely

thanks

phil
Regards,

    Michael

> Visit http://labs.ericsson.com <http://labs.ericsson.com/>  !

---

From: Michael Menth <[email-masked]>
Date: Wed, 13 May 2009 18:35:53 +0200

Hi Phil, Ingemar, and others,

> [phil] michael, true, that seems to be a way of implementing it (btw what do you do if another pkt arrives whilst TB is negative? - dont think paper mentions this). 
[Michael] The algorithms says: mark if TB is negative (no matter if 
another packet was marked before)

> i'm not sure it's the best way here, which is description to make clear the objective /behaviour of the metering, without implying a particualr implementation. 
>   
[Michael] I believe the simple example helps to show that packet-size 
independent marking is simple to implement. Other implementations are of 
course possible. If the text does not give an idea, packet-size 
independent marking remains a mysterious desire for most readers.

Regards,

    Michael

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 14 May 2009 11:08:19 +0200

Hi

Comments inline 

Regards
Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 13 maj 2009 17:58
> To: [email-masked]; Ingemar Johansson S
> Cc: [email-masked]
> Subject: RE: [PCN] draft-ietf-pcn-marking-behaviour-03.txt, 
> some comments
> 
> ingemar,
> > I have some comments on 
> draft-ietf-pcn-marking-behaviour-03. I would 
> > believe that all the comments are of the nit-picking kind 
> also it has 
> > been a few moons since I had time to delve into this area and I may 
> > have missed something so I trust you to disagree where needed :-)
> >
> > As I see it it is likely that a token bucket will introduce 
> a threshold marking pattern that is not a continuous 
> threshold-mark for all packets, this mecause the bucket level 
> may be either above or below the threshold when a packet 
> arrives. The word "all" in the sentence gives me that all 
> packets within some given time frame are marked and my 
> understand that this is not the case (I believe). But perhaps 
> I am over-interpreting the statement ?.
> 
> 
> [phil] correct, it doesnt latch into a state where every pkt 
> is marked for N secs regardless of the state of the token 
> bucket. i think by "all" it was trying to contrast with the 
> excess marking, where some pkts are always unmarked (up to 
> the excess-traffic-rate). hopefully when it gets to teh 
> formal description of the metering behaviour this is clear, 
> i'll look how to improve the Intro text (maybe just deleting 
> 'all' is enough]
[Ingemar] Now I understand the intention, I don't have any strong opinion on this, if nobody else has problems with this statment it is probably Ok

>    [I-D.charny-pcn-comparison 
> <https://mail.bt.com/exchange/EARDLEPL/Drafts/RE:%20%5BPCN%5D%
> 20draft-ietf-pcn-marking-behaviour-03.txt,%20some%20comments.E
> ML/1_text.htm#ref-I-D.charny-pcn-comparison> ].  "
[Ingemar] OK, sorry will read with the glasses on next time :-)

> 
> 
> >
> > Section 2.4, MTU : As a reader I get a bit confused here. 
> My (application view) interpretation of MTU is the maximum 
> allowed packet size that is discovered by an endpoint (is 
> this refered to as path-MTU ?). In this context however I 
> believe it is the maximum experienced packet size on the link.
> >  
> Phil, packet-size-independent marking can be achieved for 
> excess marking simply by letting the token bucket counter 
> become negative. When the counter is larger than zero, the 
> packet is not marked, otherwise it is marked. This eliminates 
> unclarities about MTUs and simplifies configuration.
> 
> 
[Ingemar] OK, maybe good it it is possible and does not cause any other problems

> 
> [phil] michael, true, that seems to be a way of implementing 
> it (btw what do you do if another pkt arrives whilst TB is 
> negative? - dont think paper mentions this). i'm not sure 
> it's the best way here, which is description to make clear 
> the objective /behaviour of the metering, without implying a 
> particualr implementation. 
> 
> > Section B.1, Competing-non-PCN-traffic: "In such cases 
> PCN-traffic and competing-non-PCN-traffic are distinguished 
> by different values of the ECN field [I-D.ietf-pcn-baseline-encoding]"
> >   I would suggest that the sentence is slightly rewritten 
> as "In such 
> > cases, and if baseline encoding 
> [I-D.ietf-pcn-baseline-encoding] is used, PCN-traffic and 
> competing-non-PCN-traffic are distinguished by different 
> values of the ECN field"
> I believe that any encoding for PCN traffic needs to make 
> sure that PCN traffic can be differentiated from non-PCN 
> traffic. I do not think that we need to make this statement 
> depending on any encoding scheme.
> 
> 
> [phil] ingemar, this really comes out of the disussions about 
> encoding, and how baseline & future extensions relate to each 
> other - and as michael says, way of distinguishing pcn & 
> competing-non-pcn traffic in way that doesnt depend on the 
> coding scheme. anyway, to shift the discussion onto the 
> encoding draft! - i just copied what the baseline encoding 
> says. It defines (S5) "Rules for Experimental Encoding Schemes":
> 
>  i guess your idea is that with some exptal encoding (you 
> have in mind?) the pcn & competing-non-pcn traffic might be 
> differentiated by something other than the ecn field? (maybe 
> dscp??) perhaps some other verb than "are distinguished" 
> would be better (which perhaps implies a method ratehr than a 
> potential method?) (maybe re-phrase as: "they differ in their 
> values of the ECN field"?). sory if i don't get your point proprely
[Ingemar] It is possible that this is not an issue. My concern is around the support for e2e ECN semantics implemented with the help of extra DSCP. In this case the ECN info at the PCN-ingress is carried by a combination of ECN and DSCP to the PCN egrees. Is it possible to distinguish between PCN and competing-non-PCN in such cases ?

> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: <[email-masked]>
Date: Thu, 14 May 2009 13:49:39 +0100

One comment inline

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ingemar Johansson S
> Sent: 14 May 2009 10:08
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Cc: Ingemar Johansson S; [email-masked]
> [Ingemar] Now I understand the intention, I don't have any strong
> opinion on this, if nobody else has problems with this statment it is
> probably Ok
> 
> >
> >
> [Ingemar] It is possible that this is not an issue. My concern is
> around the support for e2e ECN semantics implemented with the help of
> extra DSCP. In this case the ECN info at the PCN-ingress is carried by
> a combination of ECN and DSCP to the PCN egrees. Is it possible to
> distinguish between PCN and competing-non-PCN in such cases ?
> 

[Toby] Yes, I think e2e ECN can be supported using the 3 state encoding scheme. If you look at draft-ietf-3-state-encoding-00 it will hopefully be clear.