Subject: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-behaviour (including preferential dropping)

From: <[email-masked]>
Date: Tue, 9 Dec 2008 11:40:35 -0000

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. 
The proposals only affect the informative appendix - normative text is
unaltered. 
 
Comments please
Thanks
phil
 
=== Preferential dropping ==
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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-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.

== Packets not metered ==
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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-Ment
h> ]. (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'. 

== Packet size independent marking ==
   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
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-I-D.
briscoe-tsvwg-byte-pkt-mark> ] [Menth
<http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-Ment
h> ].
 
[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).

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 9 Dec 2008 12:53:21 +0100

Hi Phil,
 
thanks, doing this is a reasonable idea and I like your proposed not normative text.
 
Regards,
 
Ruediger

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 09, 2008 12:41 PM
To: [email-masked]
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. 
The proposals only affect the informative appendix - normative text is unaltered. 
 
Comments please
Thanks
phil

[existing text]

   Preferential dropping of excess-traffic-marked packets: Section 2.3 <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#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 <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-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.

 

[existing text]

   Section 2.4 <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#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 <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-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 <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#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 <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-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'. 

[existing text]

   [I-D.briscoe-tsvwg-byte-pkt-mark <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-I-D.briscoe-tsvwg-byte-pkt-mark> ] [Menth <http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01#ref-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).