Re: [PCN] PCN admission marking algorithm - consensus?

[<[e-mail]>]

> -----Original Message-----
> From: Michael Menth [mailto:[e-mail]]
> Sent: 05 March 2008 13:17
> To: Eardley,PL,Philip,CXR9 R; pcn
> Subject: Re: [PCN] PCN admission marking algorithm - consensus?
> 
> Hi,
> 
> I would like to briefly comment some issues raised along this thread.
> Possibly there were also some misunderstandings.
> 
> There was the debate concerning whether the metering and marking
> function has to be done at the head end or tail end of a link. This
has
> actually no impact on the obtained markings. Therefore, I do not
> understand why this must be standardized and the configuration must be
> consistent. If we say the location must be the same for all links of a
> domain, this is not enough for inter-operability when vendor A
> implements all function for the head end and vendor B for the tail end
> of a link. Therefore, we should provide either more flexibility or
> specify exactly where to implement the functions.

Yes, I think this is sensible. Does anyone have preferences (Joe has
said he prefers the former)

> 
> The question whether packet metering and marking is done before or
after
> packet loss occurs has more impact on the correctness of PCN than the
> above aspect. For the case of termination marking see 3.2 of
>
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-
> Eval.pdf

I think I remember from 'corridor' discussions at last ietf that the
router needs to ensure that it first drops pkts (if necessary) and then
marks them. Then everything works as expected. If I got this right, then
this seems a good thing to add. 
Thanks
phil

> Therefore, standardizing this issue could avoid different behavior of
> different equipment in challenging situations. However, this possibly
> reduces implementation options for vendors.
> 
> Regards,
> 
> Michael
> 
> 
> [e-mail] wrote:
> >
> > Here are some replies to some comments that Joe sent me (Joe replied
> > to a draft version I sent directly, but all the comments below still
> > apply to the version I sent to list) (hope that's ok joe).
> >
> > Thanks
> >
> > phil
> >
> > -----Original Message-----
> > *From:* [e-mail] [mailto:[e-mail]] *On
Behalf
> > Of *[e-mail]
> > *Sent:* 27 February 2008 11:02
> > *To:* [e-mail]
> > *Subject:* [PCN] PCN admission marking algorithm - consensus?
> >
> > I think we have consensus on the admission marking behaviour. This
is
> > a first attempt to capture that in Stds language, is it any use?
> >
> > If an interface of the PCN-domain performs PCN Admission Marking
then it
> performs three functions, which are outlined in draft-ietf-pcn-
> architecture as follows:
> >
> >    o  Packet classify - decide whether an incoming packet is a PCN-
> >       packet or not.  Another PCN WG document will specify encoding,
> >       using the DSCP and/or ECN fields.
> >
> >    o  PCN-meter - measure the 'amount of PCN-traffic'.  The
measurement
> >       is made as an aggregate of all PCN-packets, and not per flow.
> >
> >    o  PCN-mark - algorithms determine whether to PCN-mark
PCN-packets
> >       and what packet encoding is used (as specified in another PCN
WG
> >       document).
> >
> > These functions are now described in more detail.
> >
> > Note: The PCN-node MAY implement these three functions on either its
> > ingoing or outgoing interfaces. The same choice MUST be made for
every
> > PCN-node in one PCN-domain.
> >
> > [Joe] Suggest rewording "The same choice MUST be made for every
> > PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD
> > be configured so that all links within the PCN-domain support the
PCN
> > function.
> >
> > The work MUST is to strong. I believe it is OK to have a node that
> > does not support the PCN function as long as other nodes provide the
> > PCN functions, i.e., a node may provide PCN-function on both ingoing
> > and outgoing interfaces to compensate for a node that does not
provide
> > PCN function.
> >
> > My other issue is really a chart issue, if inside the PCN-domain an
> > operator configures his network in such a way that there are links
> > that can not be congested why would he need PCN-function on those
links?
> >
> > [phil] the architecture draft says "However if it's known
> >    that an interface cannot become pre-congested then it's not
strictly
> >    necessary for it to be capable of PCN-marking.  But this must be
> >    known even in unusual circumstances, eg after the failure of some
> >    links.
> >
> > I suppose this makes it a SHOULD
> >
> > Classify function:
> >
> > If a packet's ECN/DSCP fields have the value PCN, as defined in
> > [RFC-encoding], then it MUST be classified as a PCN-packet.
> >
> > If a packet's ECN/DSCP fields do not have the value PCN, as defined
in
> > [RFC-encoding], then it MUST NOT be classified as a PCN-packet.
> >
> > [Joe] I would suggest that the second line be reword to say that
"all
> > other packets are not PCN-packets".
> >
> > [PHIL] Actually this needs to be updated, since we may need to take
> > account of [quoting arch draft]:
> >
> > There may be traffic that is more important than PCN, perhaps a
> >       particular application or an operator's control messages.  A
PCN-
> >       node may dedicate capacity to such traffic or priority
schedule it
> >       over PCN.  In the latter case its traffic needs to contribute
to
> >       the PCN meters.
> >
> > Meter function:
> >
> > Note: The meter is described as a 'token bucket with threshold',
> > however the implementation is not standardised. For example, it
could
> > equally well be implemented as a virtual queue (which operates with
> > negative tokens).
> >
> > A packet classified as a PCN-packet MUST be metered as follows.
> >
> > [Joe] change MUST to MAY in above as this is only an example.
> >
> > [phil] disagree. If we make this a MAY it means the PCN standard
> > doesn't require any particular marking behaviour!!
> >
> > The interface MUST have:
> >
> > [1] a configured bit rate, termed PCN-lower-rate
> >
> > [2] a meter for PCN-packets, which MUST have the following
behaviour:
> >
> > [Joe] The above MUST can be changed to SHOULD.
> >
> > [phil] MUST seems right to me.
> >
> > a token bucket, which
> >
> > 1A tokens are added at the PCN-lower-rate, to a maximum TB.size
> >
> > 1B tokens are removed equal to the size of the PCN-packet, to a
> > minimum TB.size=0
> >
> > 2 if TB.fill < TB.threshold, then the meter indicates "admission
mark"
> > to the Mark function
> >
> > [Joe] Need to add that TB.threshold MUST be configured to be less
than
> > maximum TB.size and grater than TB.size=0
> >
> > [phil] ok, although I suppose 'equal to' is ok in both cases
> >
> > Note: Step 1A can be triggered by a packet and so can be done at the
> > same time as Step 1B.
> >
> > Note: Step 2 can be performed before or after step 1
> >
> > [Joe] The two notes are not needed.
> >
> > [phil] they were meant to make it clear that numbering doesn't imply
> > must be done in this order (which the reader might otherwise
assume)?
> >
> > If TB.fill < size of the PCN-packet, then the meter MAY:
> >
> > a. leave TB.fill unaltered and indicate "admission mark" to the Mark
> > function
> >
> > b. set TB.fill = 0 and indicate "admission mark" to the Mark
function
> >
> > c. set TB.fill = 0 and check if TB.fill < TB.threshold and if it is,
> > then indicate "admission mark" to the Mark function
> >
> > Note: Option a is expected to be the simplest to implement.
> >
> > [Joe] The above points are not needed as "1B" states that minimum TB
> > size=0, it should not go negative.
> >
> > [phil] note, if the meter does choice a, then TB.fill is unaltered.
> > This needs to stated I think.
> >
> > Mark function:
> >
> > If the meter indicates to "admission mark" a PCN-packet, then:
> >
> > [1] this step is REQUIRED, unless [RFC-encoding] standardises an
> > encoding that allows a PCN-packet to be simultaneously "admission
> > marked" and "termination marked":
> >
> > If the PCN-packet's codepoint is already "termination mark" then it
> > MUST NOT be altered, ie the following step is not performed.
> >
> > [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint
> > "admission marked", as defined in [RFC-encoding]
> >
> > [Joe]Reword the Marking function to as:
> >
> > The "admission marking" is only applied to unmarked PCN packets.
> >
> > As note could state that "termination marked" packets MUST NOT be
> > remarked, but I believe it is not needed as there may be networks
that
> > only do admission control and not flow termination.
> >
> > [phil] however, if the encoding chosen allows a pkt to be both 'adm
> > marked' & 'termin marked' then your check is unnecessary. This is
what
> > the text tries to say. However, I don't think this section should be
> > discussed too much at the moment, as hopefully we reach rapid
> > convergence on the encoding option & then we know better what to
write
> > here.
> >
> > we could also add an example algorithm, such as that in
> >
http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt
> > Fig 10.1
> > <http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-
> 00.txt%20Fig%2010.1>
> > on page 21.
> >
> > Comments?
> >
> > phil
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > PCN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pcn
> >
> 
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: [phone], fax: [phone]
> mailto:[e-mail]
> http://www3.informatik.uni-wuerzburg.de/research/ngn

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