From pcn-bounces@ietf.org Tue Dec 9 03:21:19 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0E43A6AF3; Tue, 9 Dec 2008 03:21:19 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA283A68B1 for ; Tue, 9 Dec 2008 03:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik9HqJQxXEnf for ; Tue, 9 Dec 2008 03:21:17 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 412BD3A6AF3 for ; Tue, 9 Dec 2008 03:21:17 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 11:21:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 11:21:10 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA593@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN - co-authors regarding edge node monitoring functions searched Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEA/8g+NAAASB+sA== From: To: X-OriginalArrivalTime: 09 Dec 2008 11:21:10.0965 (UTC) FILETIME=[3D255650:01C959F0] Subject: [PCN] FW: PCN - co-authors regarding edge node monitoring functions searched X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ruediger Good question, hope you don't mind me sending the answer to the list. We had a corridor meeting about this in Minneapolis. There were several people willing to help with reviews etc, although I'm sure the leaders would welcome more! - Tom volunteered to edit a CL-style edge behaviour draft - Anna volunteered to edit an SM-style edge behaviour draft Both trying for (off-list?) outline drafts in Jan, so that a reasonable I-D is in place before the next IETF draft deadline - expect they will be closely based on existing documents. Aiming to have a common structure something like: - intro - ingress behaviour - egress behaviour - info transported between the two - assumed core behaviour it would be great if anyone wanted to write draft(s) for other edge behaviour(s). best wishes, phil -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@telekom.de] Sent: 09 December 2008 10:44 To: Eardley,PL,Philip,CXR9 R Subject: PCN - co-authors regarding edge node monitoring functions searched Hi Phil, if I recall right, someone (maybe you) mentioned, that authors drafting an edge node monitoring document are searched. Are you the one organising this effort or are you at least involved in the activity? I'd be willing to contribute my thoughts to start a discussion. If there#s already a group of authors active, I'm happy to wait for their results. Regards, Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Dec 9 03:40:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297CA3A6B0F; Tue, 9 Dec 2008 03:40:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524FE3A6AB2 for ; Tue, 9 Dec 2008 03:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsOnMp3kVLG5 for ; Tue, 9 Dec 2008 03:40:42 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A67203A6B0F for ; Tue, 9 Dec 2008 03:40:41 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 11:40:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 11:40:35 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA594@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour (including preferential dropping) Thread-Index: AclZ5cj6LKiZW+ozTBSHiYWDkJ+dOQACqDZg From: To: X-OriginalArrivalTime: 09 Dec 2008 11:40:34.0933 (UTC) FILETIME=[F2ECC250:01C959F2] Subject: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour (including preferential dropping) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740630003==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1740630003== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C959F2.F30AE922" This is a multi-part message in MIME format. ------_=_NextPart_001_01C959F2.F30AE922 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We agreed in Minneapolis, & on the list, to keep the preferential dropping behaviour as a SHOULD, but add some brief explanation in the Appendix about why this isn't a MUST, http://www.ietf.org/mail-archive/web/pcn/current/msg01876.html. I've drafted some text below. Also, it made me think that we should similarly have some brief explanation about our 3 other SHOULDs or SHOULD NOTs. This is also below.=20 The proposals only affect the informative appendix - normative text is unaltered.=20 =20 Comments please Thanks phil =20 =3D=3D=3D Preferential dropping =3D=3D S2.2 says: If the PCN-node drops PCN-packets then: o PCN-packets that arrive at the PCN-node already excess-traffic- marked SHOULD be preferentially dropped; =20 Informative explanation in Appendix B4: [existing text] Preferential dropping of excess-traffic-marked packets: Section 2.3 =20 specifies: "If the PCN-node drops PCN-packets then ... PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped". Exactly what "preferentially dropped" means is left to the implementation. It is also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant. =20 [proposed new text] The optimal dropping behaviour depends on the particular edge behaviour [ref-Menth08]. A single dropping behaviour is defined, as it is simpler to standardise, implement and operate. The standardised dropping behaviour is at least adequate for all edge behaviours (and good for some), whereas others are not (for example with tail dropping far too much traffic may be terminated with the CL/SM edge behaviour, in the event of multiple bottlenecks in the PCN-domain [I-D.charny-pcn-comparison ]). The dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in recognition that other dropping behaviour may be preferred in particular circumstances, for example: (1) with the marked flow termination edge behaviour, preferential dropping of unmarked packets may be better; (2) tail dropping may make PCN marking behaviour easier to implement on current routers. =20 =20 =3D=3D Packets not metered =3D=3D A PCN-packet SHOULD NOT be metered (by this excess traffic meter function) in the following two cases: =20 o If the packet is already excess-traffic-marked on arrival at the PCN-node; =20 o If this PCN-node drops the packet. =20 Informative explanation in Appendix B6: [existing text] Section 2.4 specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If the packet is already excess- traffic-marked on arrival at the PCN-node". 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 ]. Note that an implementation could determine whether the packet is already excess-traffic-marked as an integral part of its Classification function. =20 [proposed new text] The behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT', because it may be slightly harder to implement than a metering function that is blind to previous packet markings.=20 =20 [existing text] Section 2.4 specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If this PCN-node drops the packet." This avoids over-termination [Menth ]. (A similar statement could also be made for the threshold meter function, but is irrelevant, as a link that is overloaded will already be substantially pre-congested and hence PCN-marking all packets.) =20 [proposed new text] It seems natural to do traffic conditioning before the metering functions, although for some equipment it may be harder to implement; hence the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT'.=20 =20 =20 =3D=3D Packet size independent marking =3D=3D In addition to the above, if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link ("packet size independent marking"). =20 Informative explanation in Appendix B6: [existing text] Packet size independent marking is specified as a SHOULD in Section 2.4 ( "if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link".) Without it, large packets are more likely to be excess-traffic-marked than small packets and this means that, with some edge behaviours, flows with large packets are more likely to be terminated than flows with small packets [I-D.briscoe-tsvwg-byte-pkt-mark ] [Menth ]. =20 [proposed new text] The behaviour is a 'SHOULD', rather than a 'MUST', because packet size independent marking may be slightly harder for some equipment to implement, and the impact of not doing it is moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). =20 ------_=_NextPart_001_01C959F2.F30AE922 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
We agreed in Minneapolis, & =
on the list, to keep the preferential dropping behaviour as a SHOULD, =
but add some brief explanation in the Appendix about why this =
isn’t a MUST, h=
ttp://www.ietf.org/mail-archive/web/pcn/current/msg01876.html. =
I’ve drafted some text below.
Also, it =
made me think that we should similarly have some brief explanation about =
our 3 other SHOULDs or SHOULD NOTs. This is also below. =

The =
proposals only affect the informative appendix – normative text is =
unaltered. 
 
Comments =
please
Thanks
phil
 
=3D=3D=3D =
Preferential dropping =3D=3D
S2.2 =
says:
If the =
PCN-node drops PCN-packets then:
   o  PCN-packets that arrive =
at the PCN-node already excess-traffic-
      marked SHOULD =
be preferentially dropped;

 

Informative explanation in Appendix B4:

[existing text]

   Preferential dropping of =
excess-traffic-marked packets: Section 2.3
   specifies: "If the PCN-node =
drops PCN-packets then ...  =
PCN-packets
   that arrive at the PCN-node =
already excess-traffic-marked SHOULD be
   preferentially =
dropped".  Exactly what "preferentially dropped" =
means is left to the
   implementation.  It is also =
left to the implementation what to do if
   there are no =
excess-traffic-marked PCN-packets available at =
a
   particular =
instant.
 
[proposed =
new text]
The =
optimal dropping behaviour depends on the particular edge behaviour =
[ref-Menth08]. A single dropping behaviour is defined, as it is simpler to =
standardise, implement and operate. The standardised dropping behaviour =
is at least adequate for all edge behaviours (and good for =
some), whereas others are not (for example with tail dropping far too =
much traffic may be terminated with the CL/SM edge behaviour, in the =
event of multiple bottlenecks in the PCN-domain [I-D.charny-pcn-comparison]). The dropping =
behaviour is defined as a ‘SHOULD’, rather than a =
‘MUST’, in recognition that other dropping behaviour may be =
preferred in particular circumstances, for example: (1) with the marked =
flow termination edge behaviour, preferential dropping of unmarked =
packets may be better; (2) tail dropping may make PCN marking behaviour =
easier to implement on current routers.
 
 
=3D=3D =
Packets not metered =3D=3D
A =
PCN-packet SHOULD NOT be metered (by this excess traffic =
meter
   function) in the following two =
cases:
 
   o  If the packet is already =
excess-traffic-marked on arrival at the
      =
PCN-node;
 
   o  If this PCN-node drops =
the packet.
 

Informative explanation in Appendix B6:

[existing text]

   Section 2.4 specifies: "A packet SHOULD NOT be =
metered (by this
   excess traffic meter function) =
...  If the packet is already excess-
   traffic-marked on arrival at the =
PCN-node".  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].  Note that an =
implementation could
   determine whether the packet is =
already excess-traffic-marked as an
   integral part of its =
Classification function.

 

[proposed new text]

The behaviour is defined as a ‘SHOULD NOT’, rather = than a ‘MUST NOT’, because = it may be slightly harder to implement than a metering function that is = blind to previous packet markings. 

 

[existing text]

   Section 2.4 specifies: "A packet SHOULD NOT be =
metered (by this
   excess traffic meter function) =
...  If this PCN-node drops the
   packet."  This avoids =
over-termination [Menth]. (A similar =
statement
   could also be made for the =
threshold meter function, but is
   irrelevant, as a link that is =
overloaded will already be
   substantially pre-congested and =
hence PCN-marking all packets.)
 
[proposed =
new text]
It seems =
natural to do traffic conditioning before the metering functions, =
although for some equipment it may be harder to implement; hence the =
behaviour is defined as a ‘SHOULD NOT’, rather than a =
‘MUST NOT’. 
 
 
=3D=3D Packet size =
independent marking =3D=3D
   In addition to the above, if the =
token bucket is within an MTU of
   being empty, then the meter =
SHOULD indicate to the Marking function
   that the packet is to be =
excess-traffic-marked; MTU means the =
maximum
   size of PCN-packets on the link =
("packet size independent =
marking").
 

Informative explanation in Appendix B6:

[existing text]

   Packet size independent marking =
is specified as a SHOULD in Section
   2.4 ( "if the token bucket =
is within an MTU of being empty, then the
   meter SHOULD indicate to the =
Marking function that the packet is to
   be excess-traffic-marked; MTU =
means the maximum size of PCN-packets
   on the link".)  =
Without it, large packets are more likely to =
be
   excess-traffic-marked than small =
packets and this means that, with
   some edge behaviours, flows with =
large packets are more likely to be
   terminated than flows with small =
packets
   [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth].
 
[proposed =
new text]
The =
behaviour is a ‘SHOULD’, rather than a ‘MUST’, =
because packet size independent marking may be slightly harder for some =
equipment to implement, and the impact of not doing it is moderate =
(sufficient traffic is terminated, but flows with large packets are more =
likely to be terminated).

 

=00 ------_=_NextPart_001_01C959F2.F30AE922-- --===============1740630003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1740630003==-- From pcn-bounces@ietf.org Tue Dec 9 03:53:40 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E7B3A6B0D; Tue, 9 Dec 2008 03:53:40 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AED3A6B0D for ; Tue, 9 Dec 2008 03:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2AEqVogjYN9 for ; Tue, 9 Dec 2008 03:53:30 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 1D03B3A6802 for ; Tue, 9 Dec 2008 03:53:30 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 9 Dec 2008 12:53:23 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 12:53:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 12:53:21 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C021E1AA5@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA594@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour(including preferential dropping) Thread-Index: AclZ5cj6LKiZW+ozTBSHiYWDkJ+dOQACqDZgAAEHSJA= References: <4A916DBC72536E419A0BD955EDECEDEC03DAA594@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 09 Dec 2008 11:53:22.0937 (UTC) FILETIME=[BCB0DE90:01C959F4] Cc: pcn@ietf.org Subject: Re: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour(including preferential dropping) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1339213293==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1339213293== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C959F4.BC65261A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C959F4.BC65261A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil, =20 thanks, doing this is a reasonable idea and I like your proposed not = normative text. =20 Regards, =20 Ruediger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Tuesday, December 09, 2008 12:41 PM To: pcn@ietf.org Subject: [PCN] Explanations of SHOULDs in = draft-ietf-pcn-marking-behaviour(including preferential dropping) We agreed in Minneapolis, & on the list, to keep the preferential = dropping behaviour as a SHOULD, but add some brief explanation in the = Appendix about why this isn't a MUST, = http://www.ietf.org/mail-archive/web/pcn/current/msg01876.html. I've = drafted some text below. Also, it made me think that we should similarly have some brief = explanation about our 3 other SHOULDs or SHOULD NOTs. This is also = below.=20 The proposals only affect the informative appendix - normative text is = unaltered.=20 =20 Comments please Thanks phil =20 =3D=3D=3D Preferential dropping =3D=3D S2.2 says: If the PCN-node drops PCN-packets then: o PCN-packets that arrive at the PCN-node already excess-traffic- marked SHOULD be preferentially dropped; =20 Informative explanation in Appendix B4: [existing text] Preferential dropping of excess-traffic-marked packets: Section 2.3 = =20 specifies: "If the PCN-node drops PCN-packets then ... PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped". Exactly what "preferentially dropped" means = is left to the implementation. It is also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant. =20 [proposed new text] The optimal dropping behaviour depends on the particular edge behaviour = [ref-Menth08]. A single dropping behaviour is defined, as it is simpler = to standardise, implement and operate. The standardised dropping = behaviour is at least adequate for all edge behaviours (and good for = some), whereas others are not (for example with tail dropping far too = much traffic may be terminated with the CL/SM edge behaviour, in the = event of multiple bottlenecks in the PCN-domain = [I-D.charny-pcn-comparison = ]). The dropping behaviour is defined as a = 'SHOULD', rather than a 'MUST', in recognition that other dropping = behaviour may be preferred in particular circumstances, for example: (1) = with the marked flow termination edge behaviour, preferential dropping = of unmarked packets may be better; (2) tail dropping may make PCN = marking behaviour easier to implement on current routers. =20 =20 =3D=3D Packets not metered =3D=3D A PCN-packet SHOULD NOT be metered (by this excess traffic meter function) in the following two cases: =20 o If the packet is already excess-traffic-marked on arrival at the PCN-node; =20 o If this PCN-node drops the packet. =20 Informative explanation in Appendix B6: [existing text] Section 2.4 = specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If the packet is already excess- traffic-marked on arrival at the PCN-node". 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 = ]. Note that an implementation could determine whether the packet is already excess-traffic-marked as an integral part of its Classification function. =20 [proposed new text] The behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT', = because it may be slightly harder to implement than a metering function = that is blind to previous packet markings.=20 =20 [existing text] Section 2.4 = specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If this PCN-node drops the packet." This avoids over-termination [Menth = ]. (A similar statement could also be made for the threshold meter function, but is irrelevant, as a link that is overloaded will already be substantially pre-congested and hence PCN-marking all packets.) =20 [proposed new text] It seems natural to do traffic conditioning before the metering = functions, although for some equipment it may be harder to implement; = hence the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST = NOT'.=20 =20 =20 =3D=3D Packet size independent marking =3D=3D In addition to the above, if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link ("packet size independent marking"). =20 Informative explanation in Appendix B6: [existing text] Packet size independent marking is specified as a SHOULD in Section 2.4 ( "if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link".) Without it, large packets are more likely to be excess-traffic-marked than small packets and this means that, with some edge behaviours, flows with large packets are more likely to be terminated than flows with small packets [I-D.briscoe-tsvwg-byte-pkt-mark = ] [Menth = ]. =20 [proposed new text] The behaviour is a 'SHOULD', rather than a 'MUST', because packet size = independent marking may be slightly harder for some equipment to = implement, and the impact of not doing it is moderate (sufficient = traffic is terminated, but flows with large packets are more likely to = be terminated). =20 ------_=_NextPart_001_01C959F4.BC65261A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Phil,
 
thanks, doing this is a reasonable idea and I = like your=20 proposed not normative text.
 
Regards,
 
Ruediger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: Tuesday, December 09, 2008 = 12:41=20 PM
To: pcn@ietf.org
Subject: [PCN] Explanations of = SHOULDs=20 in draft-ietf-pcn-marking-behaviour(including preferential=20 dropping)

We agreed in Minneapolis, & =
on the list, to keep the preferential dropping behaviour as a SHOULD, =
but add some brief explanation in the Appendix about why this =
isn’t a MUST, h=
ttp://www.ietf.org/mail-archive/web/pcn/current/msg01876.html. =
I’ve drafted some text below.
Also, it made me think =
that we should similarly have some brief explanation about our 3 other =
SHOULDs or SHOULD NOTs. This is also below. =

The proposals only affect the informative =
appendix – normative text is unaltered. =

 
Comments =
please
Thanks
phil
 
=3D=3D=3D Preferential dropping =
=3D=3D
S2.2 says:
If the =
PCN-node drops PCN-packets then:
   o  PCN-packets that arrive at the PCN-node =
already excess-traffic-
      marked SHOULD be preferentially =
dropped;

 

Informative explanation in Appendix=20 B4:

[existing text]

   Preferential dropping of excess-traffic-marked =
packets: Section 2.3
   specifies: =
"If the PCN-node drops PCN-packets then ...  =
PCN-packets
   that arrive at the =
PCN-node already excess-traffic-marked SHOULD =
be
   preferentially dropped".  =
Exactly what "preferentially dropped" means is left to =
the
   implementation.  It is also =
left to the implementation what to do if
   there are no excess-traffic-marked PCN-packets =
available at a
   particular =
instant.
 
[proposed new =
text]
The optimal dropping behaviour depends on the =
particular edge behaviour [ref-Menth08]. A single dropping behaviour is =
defined, as it is =
simpler to standardise, implement and operate. The =
standardised dropping behaviour is at least adequate for all edge =
behaviours =
(and good for some), whereas others are not (for example =
with tail dropping far too much traffic may be terminated with the CL/SM =
edge behaviour, in the event of multiple bottlenecks in the PCN-domain =
[I-D.charny-pcn-comparison]). The =
dropping behaviour is defined as a ‘SHOULD’, rather than a =
‘MUST’, in recognition that other dropping behaviour may =
be preferred in particular circumstances, for example: (1) with the =
marked flow termination edge behaviour, preferential dropping of =
unmarked packets may be better; (2) tail dropping may make PCN marking =
behaviour easier to implement on current =
routers.
 
 
=3D=3D Packets not metered =
=3D=3D
A PCN-packet SHOULD NOT be metered (by this =
excess traffic meter
   function) in the =
following two cases:
 
   o  If the =
packet is already excess-traffic-marked on arrival at =
the
      =
PCN-node;
 
   o  If this =
PCN-node drops the packet.
 

Informative explanation in Appendix=20 B6:

[existing text]

   Section 2.4 specifies: "A packet SHOULD NOT be metered =
(by this
   excess traffic =
meter function) ...  If the packet is already =
excess-
   traffic-marked on =
arrival at the PCN-node".  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].  Note =
that an implementation could
   determine whether the packet is already =
excess-traffic-marked as an
   integral part of its Classification =
function.

 

[proposed new =
text]

The behaviour is defined as a ‘SHOULD = NOT’, rather than=20 a ‘MUST NOT’, because=20 it may be slightly harder to implement than a metering = function=20 that is blind to previous packet markings. 

 

[existing text]

   Section 2.4 specifies: "A packet SHOULD NOT be metered =
(by this
   excess traffic =
meter function) ...  If this PCN-node drops =
the
   packet."  This avoids =
over-termination [Menth]. =
(A similar statement
   could also be made for the threshold meter function, =
but is
   irrelevant, as a link that is =
overloaded will already be
   substantially =
pre-congested and hence PCN-marking all =
packets.)
 
[proposed new =
text]
It seems natural to do traffic conditioning =
before the metering functions, although for some equipment it may be =
harder to implement; hence the behaviour is defined as a ‘SHOULD =
NOT’, rather than a ‘MUST NOT’. =

 
 
=3D=3D Packet size independent =
marking =3D=3D
   In addition to the =
above, if the token bucket is within an MTU =
of
   being empty, then the meter =
SHOULD indicate to the Marking function
   that the packet is to be excess-traffic-marked; MTU =
means the maximum
   size of =
PCN-packets on the link ("packet size independent =
marking").
 

Informative explanation in Appendix=20 B6:

[existing text]

   Packet size independent marking is specified as a =
SHOULD in Section
   2.4 ( "if the =
token bucket is within an MTU of being empty, then =
the
   meter SHOULD indicate to the =
Marking function that the packet is to
   be excess-traffic-marked; MTU means the maximum size =
of PCN-packets
   on the =
link".)  Without it, large packets are more likely to =
be
   excess-traffic-marked than small =
packets and this means that, with
   some edge behaviours, flows with large packets are =
more likely to be
   terminated than =
flows with small packets
   [I-D.briscoe-tsvwg-byte-pkt-mark] =
[Menth].
 
[proposed new =
text]
The behaviour is a ‘SHOULD’, =
rather than a ‘MUST’, because packet size independent =
marking may be slightly harder for some equipment to implement, and the =
impact of not doing it is moderate (sufficient traffic is terminated, =
but flows with large packets are more likely to be =
terminated).

 

------_=_NextPart_001_01C959F4.BC65261A-- --===============1339213293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1339213293==-- From pcn-bounces@ietf.org Tue Dec 9 04:24:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C884328C10C; Tue, 9 Dec 2008 04:24:09 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BE028C10C for ; Tue, 9 Dec 2008 04:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjgpaQifW4uM for ; Tue, 9 Dec 2008 04:24:04 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id BB6DF3A679C for ; Tue, 9 Dec 2008 04:24:03 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 12:23:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 12:23:57 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA595@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour Thread-Index: AclZ+QHnVjH4tAxOSWilxQRV4e4+Uw== From: To: X-OriginalArrivalTime: 09 Dec 2008 12:23:57.0408 (UTC) FILETIME=[021EEE00:01C959F9] Subject: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0779843456==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0779843456== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C959F9.0243C088" This is a multi-part message in MIME format. ------_=_NextPart_001_01C959F9.0243C088 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Prompted by a comment from Fortune, I've realised that a small issue needs clarifying in the marking draft.=20 =20 The draft has statements like: "PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped;" The problem is that if the baseline encoding is being used, then NO pkts are ever excess-traffic-marked! - because they are actually PCN-marked.=20 =20 At the moment, this is the simplest way I can find of making the Standard say what we mean it to say(!) is to add two Notes, one to Section 1.1 Terminology & one to Section 2.5 Marking function: =20 S1.1: Note: excess-traffic-marked means a packet that is marked as a result of the excess traffic meter function; threshold-marked means a packet that is marked as a result of the threshold meter function. [baseline-encoding] defines only two PCN encoding states available (PCN-marked and not-marked); the deployment MUST choose whether PCN-marked is interpreted as excess-traffic-marked or threshold-marked; a consistent choice MUST be made throughout a PCN-domain.=20 S2.5: Note: In some deployment scenarios there may be only two PCN encoding states available (PCN-marked and not-marked). In such scenarios, the deployment MUST choose whether the Threshold meter function or the Excess traffic meter function triggers a packet to be PCN-marked; a consistent choice MUST be made throughout a PCN-domain.=20 =20 It's a bit repetitive - is there a way of saying this just once? It would also be possible to add a similar note to the Baseline encoding draft, although initial thought is that this isn't necessary. =20 Comments? Thanks Phil/=20 ------_=_NextPart_001_01C959F9.0243C088 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Prompted by a comment from Fortune, = I’ve realised that a small issue needs clarifying in the marking draft. =

 

The draft has statements like: =
“PCN-packets that arrive at the PCN-node already =
excess-traffic-marked SHOULD be preferentially =
dropped;”
The =
problem is that if the baseline encoding is being used, then NO pkts are =
ever excess-traffic-marked! – because they are actually =
PCN-marked. 
 
At the =
moment, this is the simplest way I can find of making the Standard say =
what we mean it to say(!) is to add two Notes, one to Section 1.1 =
Terminology & one to Section 2.5 Marking =
function:
 
S1.1: =
Note: excess-traffic-marked means a packet that is marked as a result of =
the excess traffic meter function; threshold-marked means a packet that =
is marked as a result of the threshold meter function. =
[baseline-encoding] defines only two PCN encoding states available =
(PCN-marked and not-marked); the deployment MUST choose whether =
PCN-marked is interpreted as excess-traffic-marked or threshold-marked; =
a consistent choice MUST be made throughout a PCN-domain. =



S2.5: Note: In some deployment scenarios there may be only two PCN =
encoding states available (PCN-marked and not-marked). In such =
scenarios, the deployment MUST choose whether the Threshold meter =
function or the Excess traffic meter function triggers a packet to be =
PCN-marked; a consistent choice MUST be made throughout a PCN-domain. =

 
It’s a bit repetitive – is there =
a way of saying this just once?
It would =
also be possible to add a similar note to the Baseline encoding draft, =
although initial thought is that this isn’t =
necessary.
 

Comments?

Thanks

Phil/

=00 ------_=_NextPart_001_01C959F9.0243C088-- --===============0779843456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0779843456==-- From pcn-bounces@ietf.org Tue Dec 9 05:09:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB0728C12C; Tue, 9 Dec 2008 05:09:09 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AB828C12C for ; Tue, 9 Dec 2008 05:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGRySxe0JgbZ for ; Tue, 9 Dec 2008 05:09:03 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 603E228C123 for ; Tue, 9 Dec 2008 05:09:03 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 9 Dec 2008 14:08:56 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 14:08:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 14:08:55 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C021E1B4B@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA595@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] clarification of "PCM-marked" indraft-ietf-pcn-marking-behaviour Thread-Index: AclZ+QHnVjH4tAxOSWilxQRV4e4+UwABe7iA References: <4A916DBC72536E419A0BD955EDECEDEC03DAA595@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 09 Dec 2008 13:08:56.0229 (UTC) FILETIME=[4ABE5550:01C959FF] Subject: Re: [PCN] clarification of "PCM-marked" indraft-ietf-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1520715442==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1520715442== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C959FF.4A737E9E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C959FF.4A737E9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil, =20 repeating this phrase shouldn't be an issue, its not that long. And = correct description is sometimes more important than smart writing. So I = propose repetition. That also means, I agree to the proposed wording. =20 Regards, =20 Ruediger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Tuesday, December 09, 2008 1:24 PM To: pcn@ietf.org Subject: [PCN] clarification of "PCM-marked" = indraft-ietf-pcn-marking-behaviour Prompted by a comment from Fortune, I've realised that a small issue = needs clarifying in the marking draft.=20 =20 The draft has statements like: "PCN-packets that arrive at the PCN-node = already excess-traffic-marked SHOULD be preferentially dropped;" The problem is that if the baseline encoding is being used, then NO pkts = are ever excess-traffic-marked! - because they are actually PCN-marked.=20 =20 At the moment, this is the simplest way I can find of making the = Standard say what we mean it to say(!) is to add two Notes, one to = Section 1.1 Terminology & one to Section 2.5 Marking function: =20 S1.1: Note: excess-traffic-marked means a packet that is marked as a = result of the excess traffic meter function; threshold-marked means a = packet that is marked as a result of the threshold meter function. = [baseline-encoding] defines only two PCN encoding states available = (PCN-marked and not-marked); the deployment MUST choose whether = PCN-marked is interpreted as excess-traffic-marked or threshold-marked; = a consistent choice MUST be made throughout a PCN-domain.=20 neS2.5: Note: In some deployment scenarios there may be only two PCN = encoding states available (PCN-marked and not-marked). In such = scenarios, the deployment MUST choose whether the Threshold meter = function or the Excess traffic meter function triggers a packet to be = PCN-marked; a consistent choice MUST be made throughout a PCN-domain.=20 =20 It's a bit repetitive - is there a way of saying this just once? It would also be possible to add a similar note to the Baseline encoding = draft, although initial thought is that this isn't necessary. =20 Comments? Thanks Phil/=20 ------_=_NextPart_001_01C959FF.4A737E9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Phil,
 
repeating this phrase shouldn't be an issue, = its not that=20 long. And correct description is sometimes more important than smart = writing. So=20 I propose repetition. That also means, I agree to the proposed=20 wording.
 
Regards,
 
Ruediger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: Tuesday, December 09, 2008 = 1:24=20 PM
To: pcn@ietf.org
Subject: [PCN] clarification of=20 "PCM-marked" indraft-ietf-pcn-marking-behaviour

Prompted by a comment from Fortune, = I’ve realised that a=20 small issue needs clarifying in the marking draft.

 

The draft =
has statements like: “PCN-packets that arrive at the PCN-node =
already excess-traffic-marked SHOULD be preferentially =
dropped;”
The problem is that if the =
baseline encoding is being used, then NO pkts are ever =
excess-traffic-marked! – because they are actually PCN-marked. =

 
At the =
moment, this is the simplest way I can find of making the Standard say =
what we mean it to say(!) is to add two Notes, one to Section 1.1 =
Terminology & one to Section 2.5 Marking =
function:
 
S1.1: Note: =
excess-traffic-marked means a packet that is marked as a result of the =
excess traffic meter function; threshold-marked means a packet that is =
marked as a result of the threshold meter function. [baseline-encoding] =
defines only two PCN encoding states available (PCN-marked and =
not-marked); the deployment MUST choose whether PCN-marked is =
interpreted as excess-traffic-marked or threshold-marked; a consistent =
choice MUST be made throughout a PCN-domain. =


neS2.5: Note: In some deployment scenarios =
there may be only two PCN encoding states available (PCN-marked and =
not-marked). In such scenarios, the deployment MUST choose whether the =
Threshold meter function or the Excess traffic meter function triggers a =
packet to be PCN-marked; a consistent choice MUST be made throughout a =
PCN-domain. 
 
It’s a bit repetitive =
– is there a way of saying this just =
once?
It would also be possible to add a similar =
note to the Baseline encoding draft, although initial thought is that =
this isn’t necessary.
 

Comments?

Thanks

Phil/

------_=_NextPart_001_01C959FF.4A737E9E-- --===============1520715442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1520715442==-- From pcn-bounces@ietf.org Wed Dec 10 01:59:45 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511F13A68AB; Wed, 10 Dec 2008 01:59:45 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B96F3A68AB for ; Wed, 10 Dec 2008 01:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYxs98wNWZaB for ; Wed, 10 Dec 2008 01:59:43 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 99CF43A6892 for ; Wed, 10 Dec 2008 01:59:43 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id mBA9xUl6004170; Wed, 10 Dec 2008 10:59:34 +0100 (MET) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC03DAA593@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 10 Dec 2008 10:59:25 +0100 Message-ID: <003901c95aad$ff5125c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA593@E03MVB1-UKBR.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEA/8g+NAAASB+sAAvv+qQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 10 Dec 2008 10:59:34 +0100 (MET) Subject: Re: [PCN] FW: PCN - co-authors regarding edge node monitoring functionssearched X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil I am willing to get the lead on writing the LC-PCN edge behaviour! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: dinsdag 9 december 2008 12:21 > To: pcn@ietf.org > Subject: [PCN] FW: PCN - co-authors regarding edge node > monitoring functionssearched > > Ruediger > Good question, hope you don't mind me sending the answer to the list. > > We had a corridor meeting about this in Minneapolis. There > were several people willing to help with reviews etc, > although I'm sure the leaders would welcome more! > - Tom volunteered to edit a CL-style edge behaviour draft > - Anna volunteered to edit an SM-style edge behaviour draft > > Both trying for (off-list?) outline drafts in Jan, so that a > reasonable I-D is in place before the next IETF draft > deadline - expect they will be closely based on existing documents. > > Aiming to have a common structure something like: > - intro > - ingress behaviour > - egress behaviour > - info transported between the two > - assumed core behaviour > > it would be great if anyone wanted to write draft(s) for > other edge behaviour(s). > > best wishes, > phil > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@telekom.de] > Sent: 09 December 2008 10:44 > To: Eardley,PL,Philip,CXR9 R > Subject: PCN - co-authors regarding edge node monitoring > functions searched > > Hi Phil, > > if I recall right, someone (maybe you) mentioned, that > authors drafting an edge node monitoring document are > searched. Are you the one organising this effort or are you > at least involved in the activity? I'd be willing to > contribute my thoughts to start a discussion. If there#s > already a group of authors active, I'm happy to wait for > their results. > > Regards, > > Ruediger > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 10 03:40:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8733A6AB5; Wed, 10 Dec 2008 03:40:29 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178013A6A73 for ; Wed, 10 Dec 2008 03:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li9PAUTNkAdG for ; Wed, 10 Dec 2008 03:40:27 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 078E63A67EC for ; Wed, 10 Dec 2008 03:40:26 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Dec 2008 11:40:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Dec 2008 11:40:11 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA5A7@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <003901c95aad$ff5125c0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: PCN - co-authors regarding edge node monitoring functionssearched Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEA/8g+NAAASB+sAAvv+qQAANYMvA= From: To: , X-OriginalArrivalTime: 10 Dec 2008 11:40:20.0167 (UTC) FILETIME=[14896570:01C95ABC] Subject: Re: [PCN] FW: PCN - co-authors regarding edge node monitoring functionssearched X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Great! One thing that's probably worth getting some discussion on the list before you write too much, is what exactly you will include. Eg LC-PCN includes lots of options, would the draft cover just the main one or several? (personally I favour the former or something at this end of the spectrum. Across the set of edge behaviour drafts, I think our objective should be to give a few, good, likely examples of pcn usage, rather than to exhaustively cover all possibilities Eg clearly the assumed PCN-node behaviour needs to be what's in the marking draft, with guidance where that doc allows flexibility. Eg does it use baseline encoding or experimental extension? (in which case I guess a draft to describe that is needed, or at least a table with the encoding) phil { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 10 December 2008 09:59 { To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org { Subject: RE: [PCN] FW: PCN - co-authors regarding edge node monitoring { functionssearched { { Hi Phil { { I am willing to get the lead on writing the LC-PCN edge behaviour! { { Best regards, { Georgios { { { > -----Original Message----- { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > Behalf Of philip.eardley@bt.com { > Sent: dinsdag 9 december 2008 12:21 { > To: pcn@ietf.org { > Subject: [PCN] FW: PCN - co-authors regarding edge node { > monitoring functionssearched { > { > Ruediger { > Good question, hope you don't mind me sending the answer to the list. { > { > We had a corridor meeting about this in Minneapolis. There { > were several people willing to help with reviews etc, { > although I'm sure the leaders would welcome more! { > - Tom volunteered to edit a CL-style edge behaviour draft { > - Anna volunteered to edit an SM-style edge behaviour draft { > { > Both trying for (off-list?) outline drafts in Jan, so that a { > reasonable I-D is in place before the next IETF draft { > deadline - expect they will be closely based on existing documents. { > { > Aiming to have a common structure something like: { > - intro { > - ingress behaviour { > - egress behaviour { > - info transported between the two { > - assumed core behaviour { > { > it would be great if anyone wanted to write draft(s) for { > other edge behaviour(s). { > { > best wishes, { > phil { > { > -----Original Message----- { > From: Geib, Ruediger [mailto:Ruediger.Geib@telekom.de] { > Sent: 09 December 2008 10:44 { > To: Eardley,PL,Philip,CXR9 R { > Subject: PCN - co-authors regarding edge node monitoring { > functions searched { > { > Hi Phil, { > { > if I recall right, someone (maybe you) mentioned, that { > authors drafting an edge node monitoring document are { > searched. Are you the one organising this effort or are you { > at least involved in the activity? I'd be willing to { > contribute my thoughts to start a discussion. If there#s { > already a group of authors active, I'm happy to wait for { > their results. { > { > Regards, { > { > Ruediger { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { > { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 10 03:53:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857CF3A6B2B; Wed, 10 Dec 2008 03:53:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA193A6B2B for ; Wed, 10 Dec 2008 03:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDndVPEqX4YX for ; Wed, 10 Dec 2008 03:53:50 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D920E3A67EC for ; Wed, 10 Dec 2008 03:53:49 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Dec 2008 11:53:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Dec 2008 11:53:42 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA5A9@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <005801c95aa5$80114950$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour Thread-Index: AclZ+QHnVjH4tAxOSWilxQRV4e4+UwApkf0AAAdQS+A= From: To: , X-OriginalArrivalTime: 10 Dec 2008 11:53:42.0994 (UTC) FILETIME=[F30F1320:01C95ABD] Subject: Re: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321343799==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0321343799== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95ABD.F2B954C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95ABD.F2B954C8 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Fortune Yes, you=A1=AFre right - the sentences you quote from the marking = behaviour draft S2.3 & 2.4 are correct, ie both meters MUST be = implemented. However there is no compulsion about having them both = =A1=AEturned on=A1=AF =A8C the question is which meter determines the = pkt marking, if there is only the PCN-marked encoding. =20 I=A1=AFm not sure which is better: =A1=B0=A1=ADthe deployment MUST choose whether the Threshold meter = function or the Excess traffic meter function is activated;=A1=B1 or =A1=B0=A1=ADthe deployment MUST choose whether the Threshold meter = function or the Excess traffic meter function triggers a packet to be = PCN-marked;=A1=B1=20 =20 personally I think the former leaves it slightly unclear what = =A1=B0activated=A1=B1 means. However I think the latter could be = improved, so will think more about this.=20 =20 perhaps it could be solved by keeping the existing text but adding some = explanatory text to the Appendix on the lines you suggest, with a = reference to the two MUSTs in S2.3 & 2.4? =20 thanks phil=20 =20 -----Original Message----- From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: 10 December 2008 08:59 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: ??: [PCN] clarification of "PCM-marked" in = draft-ietf-pcn-marking-behaviour =20 Hi Phil, =20 I think in the scenarios you mentioned, only one of the Threshold meter = function and the Excess traffic meter takes effect. =20 If this understanding is correct, I propose to replace the second note = by something like the following: "In some deployment scenarios there may be only two PCN encoding states = available (PCN-marked and not-marked). In such scenarios, the deployment = MUST choose which of the Threshold meter function and the Excess traffic = meter function to be activated/implemented and the other MUST be = deactivated/not-implemented; a consistent choice MUST be made throughout = a PCN-domain. " =20 Besides, I would like to draw people's attention on the following = sentences in [draft-ietf-pcn-marking-behaviour]: S2.3: "A PCN-node MUST implement a Threshold Meter that has behaviour = functionally equivalent to the following." S2.4: "A PCN-node MUST implement an Excess traffic Meter that has = behaviour functionally equivalent to the following." =20 =20 Best Regards, Fortune =20 ________________________________ =B7=A2=BC=FE=C8=CB: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = =B4=FA=B1=ED philip.eardley@bt.com =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA12=D4=C29=C8=D5 20:24 =CA=D5=BC=FE=C8=CB: pcn@ietf.org =D6=F7=CC=E2: [PCN] clarification of "PCM-marked" in = draft-ietf-pcn-marking-behaviour Prompted by a comment from Fortune, I=A1=AFve realised that a small = issue needs clarifying in the marking draft.=20 =20 The draft has statements like: =A1=B0PCN-packets that arrive at the = PCN-node already excess-traffic-marked SHOULD be preferentially = dropped;=A1=B1 The problem is that if the baseline encoding is being used, then NO pkts = are ever excess-traffic-marked! =A8C because they are actually = PCN-marked.=20 =20 At the moment, this is the simplest way I can find of making the = Standard say what we mean it to say(!) is to add two Notes, one to = Section 1.1 Terminology & one to Section 2.5 Marking function: =20 S1.1: Note: excess-traffic-marked means a packet that is marked as a = result of the excess traffic meter function; threshold-marked means a = packet that is marked as a result of the threshold meter function. = [baseline-encoding] defines only two PCN encoding states available = (PCN-marked and not-marked); the deployment MUST choose whether = PCN-marked is interpreted as excess-traffic-marked or threshold-marked; = a consistent choice MUST be made throughout a PCN-domain.=20 S2.5: Note: In some deployment scenarios there may be only two PCN = encoding states available (PCN-marked and not-marked). In such = scenarios, the deployment MUST choose whether the Threshold meter = function or the Excess traffic meter function triggers a packet to be = PCN-marked; a consistent choice MUST be made throughout a PCN-domain.=20 =20 It=A1=AFs a bit repetitive =A8C is there a way of saying this just once? It would also be possible to add a similar note to the Baseline encoding = draft, although initial thought is that this isn=A1=AFt necessary. =20 Comments? Thanks Phil/=20 ------_=_NextPart_001_01C95ABD.F2B954C8 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Fortune

Yes, you=A1=AFre right - the = sentences you quote from the marking behaviour draft S2.3 & 2.4 are correct, ie = both meters MUST be implemented. However there is no compulsion about having = them both =A1=AEturned on=A1=AF =A8C the question is which meter determines = the pkt marking, if there is only the PCN-marked encoding.

 

I=A1=AFm not sure which is = better:

=A1=B0=A1=ADthe = deployment MUST choose whether the Threshold meter function or the Excess traffic meter = function is activated;=A1=B1

or

=A1=B0=A1=ADthe = deployment MUST choose whether the Threshold meter function or the Excess traffic meter = function triggers a packet to be PCN-marked;=A1=B1 =

 

personally I think the former = leaves it slightly unclear what =A1=B0activated=A1=B1 means. However I think the = latter could be improved, so will think more about this.

 

perhaps it could be solved by = keeping the existing text but adding some explanatory text to the Appendix on the = lines you suggest, with a reference to the two MUSTs in S2.3 & = 2.4?

 

thanks

phil

 

-----Original Message-----
From: Fortune HUANG [mailto:fqhuang@huawei.com]
Sent: 10 December 2008 = 08:59
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: ??: [PCN] = clarification of "PCM-marked" in = draft-ietf-pcn-marking-behaviour

 

Hi Phil,

 

I think in the scenarios you = mentioned, only one of the Threshold meter function and the Excess traffic = meter takes = effect.

 

If this understanding is correct, = I propose to replace the second note by something like the = following:

"In some deployment scenarios there may be only two PCN = encoding states available (PCN-marked and not-marked). In such scenarios, the = deployment MUST choose which of the Threshold meter function and the Excess traffic = meter function to be activated/implemented and the other MUST be deactivated/not-implemented; a consistent choice MUST be = made throughout a PCN-domain. "

 

Besides, I would like to draw = people's attention on the following sentences in = [draft-ietf-pcn-marking-behaviour]:

S2.3: "A PCN-node MUST = implement a Threshold Meter that has behaviour functionally equivalent to the following."

S2.4: "A PCN-node MUST = implement an Excess traffic Meter that has behaviour functionally equivalent to the following."

 

 

Best Regards,

Fortune

 

=B7=A2=BC=FE=C8=CB: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = =B4=FA=B1=ED philip.eardley@bt.com
=B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA12=D4=C29=C8=D5 20:24
=CA=D5=BC=FE=C8=CB: pcn@ietf.org
=D6=F7=CC=E2: [PCN] clarification of "PCM-marked" in draft-ietf-pcn-marking-behaviour

Prompted by a comment from Fortune, I=A1=AFve = realised that a small issue needs clarifying in the marking draft.

 

The draft has statements like: =
=A1=B0PCN-packets that arrive at the PCN-node already =
excess-traffic-marked SHOULD be preferentially =
dropped;=A1=B1
The =
problem is that if the baseline encoding is being used, then NO pkts are =
ever excess-traffic-marked! =A8C because they are actually PCN-marked. =

 
At the =
moment, this is the simplest way I can find of making the Standard say =
what we mean it to say(!) is to add two Notes, one to Section 1.1 =
Terminology & one to Section 2.5 Marking =
function:
 
S1.1: =
Note: excess-traffic-marked means a packet that is marked as a result of =
the excess traffic meter function; threshold-marked means a packet that =
is marked as a result of the threshold meter function. =
[baseline-encoding] defines only two PCN encoding states available =
(PCN-marked and not-marked); the deployment MUST choose whether =
PCN-marked is interpreted as excess-traffic-marked or threshold-marked; =
a consistent choice MUST be made throughout a PCN-domain. =






S2.5: Note: In some deployment scenarios =
there may be only two PCN encoding states available (PCN-marked and =
not-marked). In such scenarios, the deployment MUST choose whether the =
Threshold meter function or the Excess traffic meter function triggers a =
packet to be PCN-marked; a consistent choice MUST be made throughout a =
PCN-domain. 
 
It=A1=AFs =
a bit repetitive =A8C is there a way of saying this just =
once?
It would =
also be possible to add a similar note to the Baseline encoding draft, =
although initial thought is that this isn=A1=AFt =
necessary.
 

Comments?

Thanks

Phil/

=00 ------_=_NextPart_001_01C95ABD.F2B954C8-- --===============0321343799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0321343799==--