Subject: Re: [PCN] PCN elevator speech

From: <[email-masked]>
Date: Thu, 7 May 2009 17:48:30 +0100

Fred,

To let you know that in the draft-ietf-pcn-marking-behaviour  [currently
updating]

Have added in Section B.5 the sentence 
The PCN-threshold-rate is configured at less than the rate allocated to
the PCN-traffic class.

And in B.6
The PCN-excess-rate is configured at less than (or possibly equal to)
the rate allocated to the PCN-traffic class.

phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fred
{ Baker
{ Sent: 25 April 2009 00:54
{ To: Tom Taylor
{ Cc: pcn
{ Subject: Re: [PCN] PCN elevator speech
{ 
{ I have an additional edit.
{ 
{ Generally, one doesn't configure a link to run full-bore and then
{ scale back to deal with the traffic it has. r\Rather, one configures a
{ link to deal effectively with specific application classes. For
{ example, one will generally have a class for real-time traffic or
{ separate classes for voice and video, with a separate class for
{ elastic applications. This results in the real time traffic being
{ handled in a way that serves its needs (it is guaranteed at most a
{ given latency on a link so that e2e delay variation doesn't exceed
{ some threshold), allowing elastic traffic to do the things it is
{ famous for doing without interrupting real-time services.
{ 
{ As such, the reference to "the rate of the link" should refer to the
{ "the rate allocated to a traffic class". If the class in fact occupies
{ the whole link, the two statements are equivalent. If that observation
{ gives heartburn, I would suggest "the rate of a traffic class, or
{ where appropriate, a link".
{ 
{ It would also be very nice if we could somehow provide an architecture
{ in which we are not using one mechanism differently for two different
{ purposes, but using one mechanism to serve one purpose interpreted
{ differently by different use cases. We are willing to have pre-
{ congestion notification for voice/video/etc, but are willing to build
{ queues for data in some cases, and in other cases have had suggestions
{ that folks could similarly manage RFC 3168-like ECN based on traffic
{ rates in elastic classes. If we are building an architecture for ECN
{ in general of which PCN and RFC 3168 are special cases, then that
{ should be reflected in this proposed text.
{ 
{ On Apr 24, 2009, at 4:06 PM, Tom Taylor wrote:
{ 
{ > Having said this, I would beg the indulgence of the group to modify
{ > the second-last sentence slightly, so it reads:
{ >
{ > "The level of marking allows decisions to be made about whether to
{ > admit or terminate."
{ >
{ > Tom Taylor wrote:
{ >> Here is the text that is proposed to begin all PCN-related
{ >> documents. Phil actually did the work, with input from others.
{ >> The objective of Pre-Congestion Notification (PCN) is to protect
the
{ >> quality of service (QoS) of inelastic flows within a Diffserv
{ >> domain, in
{ >> a simple, scalable and robust fashion. Two mechanisms are used:
{ >> admission control, to decide whether to admit or block a new flow
{ >> request, and (in abnormal circumstances) flow termination to decide
{ >> whether to terminate some of the existing flows. Together they
{ >> protect
{ >> the QoS of previously admitted flows. To achieve this, the overall
{ >> rate
{ >> of the PCN-traffic is metered on every link in the PCN-domain, and
{ >> PCN-packets are appropriately marked when certain configured rates
{ >> are
{ >> exceeded. These configured rates are below the rate of the link
thus
{ >> providing notification before any congestion occurs (hence
{ >> "pre-congestion notification"). The level of marking allows the
{ >> boundary
{ >> nodes to make decisions about whether to admit or terminate. For a
{ >> full description of the PCN architecure see [RFC xxxx (the
{ >> architecture document)].
{ >> _______________________________________________
{ >> PCN mailing list
{ >> [email-masked]
{ >> https://www.ietf.org/mailman/listinfo/pcn
{ > _______________________________________________
{ > PCN mailing list
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn