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

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 16 Jan 2009 08:43:08 +0000

Hi Phil

I agree with the proposed changes!

Best regards,
Georgios

On 12/9/2008, "[email-masked]" <[email-masked]> wrote:

>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: <[email-masked]>
Date: Fri, 16 Jan 2009 08:50:06 -0000

Great - thanks!
I think basically this marking draft [& the baseline encoding] is ready
for WG last call - but I think we have to wait for the architecture to
go through IETF last call?(am hoping the 09 version I sent earlier this
week will be OK for that)
best wishes
phil

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 16 January 2009 08:43
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]
{ Subject: Re: [PCN] Explanations of SHOULDs in draft-ietf-pcn-marking-
{ behaviour (including preferential dropping)
{ 
{ Hi Phil
{ 
{ I agree with the proposed changes!
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ On 12/9/2008, "[email-masked]" <[email-masked]> wrote:
{ 
{ >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-Men
t
{ >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-Men
t
{ >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