Subject: [PCN] Revised 3-in-1 draft and status of RFC5696

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 4 May 2011 10:23:09 +0100

I'll get back to this in the next couple of days and try and release an
updated draft early next week... We had more or less converged on what text
to include in the new version.

Meanwhile, can the working group give their views on what should happen
regarding RFC5696. As I see it there are 3 options:

1) have this new RFC update it, but that leaves it as a dead document (in
effect, since there will be contradictory definitions for the 01 codepoint)
2) release a bis version of RFC5696 with the EXP codepoint fixed as having
to be used for carrying a PCN marking state, and with any other tweaks we
think of
3) combine the two by putting in a section in this document about how to use
it in single marking schemes (which will take quite a bit of wordsmithing).

I personally favour option 2 as it is the cleanest and allows us to keep
open the greatest range of future marking schemes. Option 1 is easy, but
leaves some potential issues (for instance it will mean there is no
standards support for anything similar to the PSDM scheme which Michael and
others seem to still be interested in). Option 3 will take a lot of work,
but would allow RFC5696 to become obsolete (so is also quite clean from a
standards viewpoint).

Toby

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 16 April 2011 12:05
> To: Toby Moncaster
> Cc: 'Michael Menth'; [email-masked]
> Subject: RE: [PCN] ECN handling with 3-in-1
> 
> Toby,
> 
> At 09:54 16/04/2011, Toby Moncaster wrote:
> >Bob, Michael,
> >
> > > -----Original Message-----
> > > From: Bob Briscoe [mailto:[email-masked]]
> > > Sent: 15 April 2011 15:51
> > > To: Michael Menth
> > > Cc: Toby Moncaster; [email-masked]
> > > Subject: Re: [PCN] ECN handling with 3-in-1
> > >
> > > Toby, Michael,
> > >
> > > 2/ e2e ECN appendix
> > > Now that I'm awake, I've realised the wording of the headings for
> the
> > > four options we are discussing needs to be completely reframed.
> > >
> > > End nodes don't ask for PCN control, they ask for admission
> control.
> > > An operator chooses what mechanism to use for admission control
> over
> > > their segment of the path, and PCN is just one possible mechanism
> > > they might choose.
> > >
> > > At the outset, we need to list the two main ways that end-nodes
> tell
> > > the network that they need admission control, which in turn makes
> the
> > > PCN-ingress remark their traffic with a PCN-compatible DSCP:
> > >
> > > A) flow signalling associates a filterspec with a need for
> admission
> > > control (e.g. thru RSVP or some equivalent message down from a SIP
> > > server to the ingress), and the PCN ingress remarks traffic
> matching
> > > that filterspec to a PCN-compatible DSCP, as its chosen admission
> > > control mechanism.
> > >
> > > B) Traffic arrives with a DSCP that implies it requires admission
> > > control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
> > > Broadcast TV when used for video on demand, and Multimedia
> > > Conferencing [RFC4594, RFC5865].
> >
> >You need to re-read the appendix of RFC5696 where we discuss DSCP-
> related
> >issues.
> 
> I did before writing that email.
> 
> >I am very unkeen to add so much extra text to what should be a simple
> >encoding document. This will end up making the appendix nearly as long
> as
> >the main document. I also have concerns that this sort of thing is
> really
> >architectural. This document isn't about telling operators which of
> their
> >traffic they should be doing admission control on.
> >
> >I would rather we just put a simple paragraph saying what you have in
> your
> >intro to this point:
> >
> >" End nodes don't ask for PCN control, they ask for admission control.
> >  An operator chooses what mechanism to use for admission control over
> >  their segment of the path, and PCN is just one possible mechanism
> >  they might choose."
> 
> We need to provide some explanation for why we suddenly started
> talking about these four cases. So we do need to say what we mean by
> end-nodes asking for admission control. It would be nice to cite
> something that explains, but we don't have anything, because RFC5865
> on DSCPs for admission contrl went through after all the PCN RFCs so
> far.
> 
> So I think we have to treat this appendix as the latest definitive
> word on the two mains ways that end points might use to signal that
> they want admission control, even tho it's not really relevant to
> this doc. The only alternative would be to update the PCN
> architecture RFC, and I don't want to go there.
> 
> > > We need to define two phrases, such as:
> > > * "Traffic that requires admission control" as traffic that uses
> > > either method A or B.
> > > * "Traffic that does not require admission control" as traffic that
> > > uses neither of methods A or B.
> >
> >OK, happy to have those definitions, but we are going to find
> ourselves
> >tying knots as we try and talk about traffic that doesn't need
> admission
> >control but which shares the same DSCP...
> 
> [snip]
> 
> > > >>>>     ECN traffic not subjected to PCN control but sharing a
> PCN-
> > > >>>compatible
> > > >>>>     DSCP:
> > > >>>s/sharing a PCN-compatible DSCP/using a PCN-compatible DSCP on
> > > >>>arrival at the PCN ingress/
> > >
> > > On second thoughts, we should head this item
> > > "ECN capable traffic that does not require admission control but
> > > carries a DSCP that the PCN-ingress is using for PCN-capable
> traffic."
> > >
> > > HOWEVER, I don't think this case is possible. If traffic arrives
> with
> > > a DSCP that would be used for PCN, it is signalling that it
> requires
> > > admission control [RFC5865].
> >
> >BUT some of that traffic may in fact be automatically admitted
> (because of
> >policy), hence it wouldn't use PCN...
> >
> >My own view is this whole case needn't be mentioned because the
> traffic is
> >neither ECN nor PCN. If we were to list all negative cases we would
> get an
> >even longer appendix!
> 
> Well, the traffic *is* ECN and it is confusable with PCN traffic. As
> I just said in my mail to Michael, it would only be confusible with
> PCN traffic if the PCN operator decided to use weird DSCPs for PCN.
> 
> How about not listing this case as if it is normal, but instead
> mention it as a 'footnote' to this appendix, as an abnormal case to
> be avoided if possible, perhaps:
> 
> "It is strongly RECOMMENDED that the advice in A.1 of the PCN
> baseline encoding [RFC5696] is followed when choosing which DSCP
> indicates PCN-compatible traffic. Otherwise nodes within the PCN
> region will mistake traffic using e2e ECN for PCN-traffic if it also
> happens to use the chosen DSCP. To avoid this confusion, the PCN
> ingress would have to remark this traffic to another DSCP, causing
> further complication and confusion downstream."
> 
> > >
> > > >>>>     ECN traffic being subjected to PCN control, receiver
> indicates
> > > >>>desire
> > > >>>>     to see PCN marks:
> > >
> > > We should head this item
> > > "Traffic that requires admission control, where the e2e transport
> > > somehow indicates it wants to see PCN marks."
> >
> >s/"somehow indicates"/"signals that"
> 
> If you want.
> I was trying to avoid being prescriptive about how it might be done.
> 
> >I'll try and unravel all the changes and send a revised version by
> Monday...
> >It won't necessarily include all the suggestions (see the inline
> comment at
> >the top), and there is a chance I may miss a couple!
> 
> Yes, when I prepared the email you just replied to, I tried to pull
> together everything that had been said, so I hope that posting will
> be useful for you.
> 
> Cheers
> 
> 
> Bob
> 
> 
> >Toby
> >
> >
> > >
> > >
> > > Bob
> > >
> > > >>>>The
> > > >>>PCN-
> > > >>>>        egress should not zero the ECN field,
> > > >>>Don't agree. ECN should never leak into PCN, but PCN might be OK
> to
> > > >>>leak to ECN receiver.
> > > >>I'm not allowing ECN to leak into PCN. I am (in limited
> > > circumstances)
> > > >>allowing the PCN-domain to over-write the ECN information and
> hence
> > > leak PCN
> > > >>information to the receiver.
> > > >>
> > > >>>Reasoning: admission of a flow should only depend on PCN marking
> > > >>>within the PCN region. It shouldn't depend on ECN marking from
> > > queues
> > > >>>outside the PCN region, which will not have been configured to
> give
> > > >>>good signals at the right load levels.
> > > >>Oh, I think I see your point. RFC6040 tunnels will set the ECN of
> the
> > > outer
> > > >>header to whatever is in the inner header. BUT you are forgetting
> > > that the
> > > >>default behaviour of the PCN-ingress is to clear whatever is in
> the
> > > outer
> > > >>header and set it to 10 (if the traffic is PCN) or 00 (if the
> traffic
> > > is
> > > >>not-PCN)
> > > >
> > > >Mentioning that would be helpful. Also we need to remember that
> but
> > > >often forget about it and then we wonder about the text ...
> > > >
> > > >Regards,
> > > >
> > > >     Michael
> > > >
> > > >>>The reverse argument seems less likely to apply to leaking PCN
> to
> > > >>>receiver, because any decent level of PCN will usefully trigger
> a
> > > >>>lower rate, thus potentially avoiding the need to block
> admissions.
> > > >>>
> > > >>>>and the tunnel egress should
> > > >>>>        use [RFC6040] normal mode (preserving any PCN-marking).
> > > >>>There are no modes for an RFC6040 egress. Modes are only for the
> > > >>>ingress.
> > > >>OK, noted. I did know that really, I was being careless.
> > > >>
> > > >>>The important point is not what the tunnel egress does (assuming
> the
> > > >>>arrangement in the Fig below), but that the PCN egress doesn't
> zero
> > > >>>the outer ECN field.
> > > >>Indeed...
> > > >>
> > > >>>>Note that
> > > >>>>        this may turn ECT(0) into ECT(1) and so is not
> compatible
> > > with
> > > >>>the
> > > >>>>        experimental ECN nonce [RFC3540].
> > > >>>s/this/PCN marking on interior nodes/
> > > >>>
> > > >>>
> > > >>>>     In the list above any form of IP-in-IP tunnel can be used
> > > unless
> > > >>>>     specified otherwise.  We assume a logical separation of
> > > tunneling
> > > >>>>     and PCN actions in both PCN-ingress and PCN-egress nodes.
> > > That
> > > >>>is,
> > > >>>>     any tunneling action happens wholly outside the PCN-domain
> as
> > > >>>>     illustrated in the following figure:
> > > >>>>
> > > >>>>
> > > >>>>                  ,  .  .  .  .  PCN-domain  .  .  .  .  .  .
> .
> > > >>>>                 .   ,--------.                   ,--------.
> .
> > > >>>>                .   _|  PCN-   |___________________|  PCN-  |_
> .
> > > >>>>                .  / | ingress |                   | egress | \
> .
> > > >>>>                 .|  '---------'                   '--------'
> |.
> > > >>>>                  | .  .  .  .  .  .  .  .  .  .  .  .  .  .
> .|
> > > >>>>             ,--------.                                     ,--
> ----
> > > --.
> > > >>>>       _____| Tunnel  |                                     |
> > > Tunnel
> > > >>>|____
> > > >>>>            | Ingress | - - ECN preserved inside tunnel - - |
> > > Egress |
> > > >>>>            '---------'                                     '--
> ----
> > > --'
> > > >>>>
> > > >>>>
> > > >>>>               Figure 4: Separation of tunneling and PCN
> actions
> > > >>>>"
> > > >>>nice ASCII art.
> > > >>Thanks :)
> > > >>
> > > >>>
> > > >>>>I hope this captures all the key elements from the discussion.
> > > >>>>
> > > >>>>I am still unsure exactly how we are proceeding with regards to
> > > >>>updating
> > > >>>>RFC5696. Can this document both update RFC5696 AND be dependent
> on
> > > it
> > > >>>as
> > > >>>>well? Currently I am thinking of adding the following as a
> > > standalone
> > > >>>>section:
> > > >>>>
> > > >>>>"Section N. Effect on baseline encoding
> > > >>>>
> > > >>>>The baseline encoding [rfc5696] specified that the 01 codepoint
> was
> > > >>>for use
> > > >>>>in experimental schemes. It also gave guidelines for such
> > > experiments.
> > > >>>This
> > > >>>>document updates the 01 codepoint and fixes its meaning.
> > > Consequently
> > > >>>this
> > > >>>>document updates [rfc5696]. People wishing to use the 01
> codepoint
> > > for
> > > >>>>experimental schemes as described in [rfc5696] must accept the
> risk
> > > >>>that
> > > >>>>PCN-nodes compatible with this encoding scheme may not be
> > > compatible
> > > >>>with
> > > >>>>their experiment."
> > > >>>It would be dangerous for me to respond to this now - I'm too
> tired
> > > >>>to think straight. But my gut feeling is that the wording should
> > > lean
> > > >>>more towards "updates", and less towards appearing to encourage
> more
> > > >>>experimentation, which would run counter to interoperability -
> the
> > > >>>raison d'etre of a standards body.
> > > >>OK, I can probably highlight that we are not recommending people
> > > start
> > > >>experiments, but if they are already using the EXP codepoint for
> > > anything
> > > >>else they need to be aware of this clash...
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Two inline responses to Michael at the end
> > > >>>One from me too...
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Toby
> > > >>>>
> > > >>>>>-----Original Message-----
> > > >>>>>From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > >>>Of
> > > >>>>>Toby Moncaster
> > > >>>>>Sent: 01 April 2011 14:58
> > > >>>>>To: 'Bob Briscoe'; 'Michael Menth'
> > > >>>>>Cc: [email-masked]
> > > >>>>>Subject: Re: [PCN] ECN handling with 3-in-1
> > > >>>>>
> > > >>>>>I'm not sure if I captured all the changes we intend to do on
> this
> > > >>>>>draft:
> > > >>>>>
> > > >>>>>1) add Michael's text on e2e ECN (once it has become stable)
> > > >>>>>
> > > >>>>>2) add a brief paragraph explaining that this effectively
> updates
> > > >>>>>RFC5696
> > > >>>>>and that therefore anyone running experiments with that are on
> > > >>>their
> > > >>>>>own
> > > >>>>>(which they kind of are anyway, if they are doing an
> experiment!).
> > > >>>>>
> > > >>>>>3) clarify how to do single marking with this encoding.
> > > >>>>>
> > > >>>>>I now recall the real reason why I wanted to preserve baseline
> > > >>>which is
> > > >>>>>that
> > > >>>>>this encoding has the RFC6040 dependency.
> > > >>>>>
> > > >>>>>Is there any mileage in exploring a bis for RFC5696? As I see
> it
> > > we
> > > >>>are
> > > >>>>>always going to have a slightly messy situation. For instance
> I am
> > > >>>not
> > > >>>>>sure
> > > >>>>>if you are allowed the circular dependency of 3-in-1 encoding
> > > being
> > > >>>>>dependent on RFC5696 but also updating RFC5696.
> > > >>>>>
> > > >>>>>Of course we could always revive the option we discussed,
> where we
> > > >>>>>obsolete
> > > >>>>>RFC5696 and incorporate a baseline behaviour within this draft
> > > >>>(which
> > > >>>>>could
> > > >>>>>then be called PCN encodings using a single DSCP)...
> > > >>>>>
> > > >>>>>Thoughts anyone?
> > > >>>>>
> > > >>>>>Toby
> > > >>>>>
> > > >>>>>>-----Original Message-----
> > > >>>>>>From: Bob Briscoe [mailto:[email-masked]]
> > > >>>>>>Sent: 01 April 2011 13:22
> > > >>>>>>To: Michael Menth
> > > >>>>>>Cc: Toby Moncaster; [email-masked]
> > > >>>>>>Subject: Re: [PCN] ECN handling with 3-in-1
> > > >>>>>>
> > > >>>>>>Michael,
> > > >>>>>>
> > > >>>>>>At 09:36 01/04/2011, Michael Menth wrote:
> > > >>>>>>>Hi all,
> > > >>>>>>>
> > > >>>>>>>to quickly see that the case analysis is complete, I suggest
> a
> > > >>>>>>>slight rewording:
> > > >>>>>>>
> > > >>>>>>>Handling of ECN traffic
> > > >>>>>>>* ECN traffic not being subject to PCN control and not
> sharing a
> > > >>>>>>>PCN-compatible DSCP
> > > >>>>>>>      - no action needed
> > > >>>>>>>* ECN traffic not being subject to PCN control and sharing a
> > > >>>>>>>PCN-compatible DSCP
> > > >>>>>>>      - ingress tunnels that traffic with an non-PCN-
> compatible
> > > >>>DSCP
> > > >>>>>>>in the outer header (any tunnel may be used)
> > > >>>>>>>      - alternative: ingress maps the DSCP to a local DSCP
> and
> > > >>>egress
> > > >>>>>>>re-maps it to the original PCN-compatible DSCP
> > > >>>>>>>      - alternative: ingress tunnels that traffic with not-
> PCN
> > > in
> > > >>>the
> > > >>>>>>>outer header (any tunnel may be used); note that this turns
> of
> > > >>>ECN
> > > >>>>>>>for this traffic within the PCN domain.
> > > >>>>>>We ought to recommend one:
> > > >>>>>>#2 does nothing wrong, whereas the others do, to a certain
> > > >>>extent.
> > > >>>>>>THe only reason for using #3 would be if you are short of
> DSCPs
> > > >>>(e.g.
> > > >>>>>>MPLS or Ethernet).
> > > >>>>>>#1 changes the PHB, whereas #2 doesn't and is otherwise the
> same.
> > > >>>So
> > > >>>>>>#1 can be chucked.
> > > >>>>>>
> > > >>>>>>>* ECN traffic being subject to PCN control
> > > >>>>>>>      - ingress drops CE-marked packets and egress zeros ECN
> > > >>>field of
> > > >>>>>>>PCN packets which disables end-to-end ECN
> > > >>>>>>Not recommended
> > > >>>>>>
> > > >>>>>>>      - alternative: ingress tunnels that traffic with a
> > > >>>>>>>PCN-compatible DSCP in the outer header and the egress zeros
> > > >>>>>>>ECN-field before decapsulation (any tunnel may be used)
> > > >>>>>>recommended
> > > >>>>>>
> > > >>>>>>>* ECN traffic being subject to PCN control, and the receiver
> has
> > > >>>>>>>indicated to receive PCN marks
> > > >>>>>>>      - ingress tunnels that traffic with a PCN-compatible
> DSCP
> > > >>>but
> > > >>>>>>>the egress SHOULD NOT zero the ECN field before
> decapsulation
> > > >>>>>>>according to RFC6040 normal mode; note that this may turn
> > > >>>ECT(0)
> > > >>>>>>>into ECT(1) so that the nonce is modified.
> > > >>>>>>Good point.
> > > >>>>>>This needs to be clearly flagged as an experimental only
> scheme.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>Another two questions
> > > >>>>>>>* Traffic may arrive with a non-PCN-compatible DSCP and is
> > > >>>subject
> > > >>>>>>>to PCN control. Do we care about the original DSCP? This
> seems
> > > >>>to be
> > > >>>>>>>a similar issue.
> > > >>>>>>Similar to what?
> > > >>>>What Michael means is, if an operator chooses to change the
> DSCP of
> > > an
> > > >>>>arriving packet in order to enable PCN for that packet, should
> that
> > > >>>change
> > > >>>>be reversed on leaving the PCN domain? This is starting to get
> > > rather
> > > >>>>obscure. Appendix A.1 of RFC5696 discusses the choice of
> suitable
> > > >>>DSCPs for
> > > >>>>PCN and makes it clear that operators should choose to use an
> > > existing
> > > >>>DSCP
> > > >>>>providing suitable scheduling and priority. However, if an
> operator
> > > >>>chooses
> > > >>>>to define a local DSCP instead then they are free to do so. If
> I
> > > >>>recall
> > > >>>>right, DSCPs are not guaranteed to survive between domains
> > > anyway...
> > > >>>>
> > > >>>>
> > > >>>>>>>* How is the ECN-field of traffic with a PCN-compatible DSCP
> > > >>>>>>>interpreted outside a PCN domain? I guess with ECN
> semantics?
> > > >>>Have
> > > >>>>>>>we stated that somewhere. Do we need to state it?
> > > >>>>>>Dunno whether we've said this somewhere. Will need to check.
> > > >>>>Is this at all relevant to PCN? I would argue we don't need to
> > > state
> > > >>>this
> > > >>>>anywhere at all since PCN semantics only apply inside a PCN-
> domain.
> > > IN
> > > >>>>appendix A.1 of RFC5696 we make it clear that PCN is a marking
> > > >>>behaviour for
> > > >>>>use within the PCN-domain and discuss DSCP-related issues
> > > >>>Given we are talking about e2e ECN support across a PCN domain,
> it
> > > >>>would do no harm to reinforce the idea that a DSCP cannot even
> be
> > > >>>considered PCN-compatible when it is outside a PCN domain - it
> has
> > > >>>its usual scheulding PHB, but its congestion marking behaviour
> is
> > > the
> > > >>>ECN default, not PCN.
> > > >>Would adding the following (in a suitable place) suffice?:
> > > >>
> > > >>"PCN is in effect a congestion marking behaviour for use with
> > > realtime
> > > >>traffic in a controlled domain. As such, within the PCN-domain,
> PCN
> > > marking
> > > >>replaces ECN marking for any PCN-enabled DSCPs. Outside the PCN-
> > > domain, ECN
> > > >>remains the default behaviour for all DSCPs."
> > > >>
> > > >>Toby
> > > >>
> > > >>>
> > > >>>Bob
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>>
> > > >>>>>>Bob
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>Best wishes,
> > > >>>>>>>
> > > >>>>>>>      Michael
> > > >>>>>>>
> > > >>>>>>>--
> > > >>>>>>>Prof. Dr. habil. Michael Menth
> > > >>>>>>>University of Tuebingen
> > > >>>>>>>Faculty of Science
> > > >>>>>>>Department of Computer Science
> > > >>>>>>>Chair of Communication Networks
> > > >>>>>>>Sand 13, 72076 Tuebingen, Germany
> > > >>>>>>>phone: (+49)-7071/29-70505
> > > >>>>>>>fax: (+49)-7071/29-5220
> > > >>>>>>>mailto:[email-masked]
> > > >>>>>>>http://www-kn.informatik.uni-tuebingen.de
> > >
> >>>>>>________________________________________________________________
> > > >>>>>>Bob Briscoe,                                BT Innovate&
> Design
> > > >>>>>_______________________________________________
> > > >>>>>PCN mailing list
> > > >>>>>[email-masked]
> > > >>>>>https://www.ietf.org/mailman/listinfo/pcn
> > > >>>________________________________________________________________
> > > >>>Bob Briscoe,                                BT Innovate&  Design
> > > >
> > > >--
> > > >Prof. Dr. habil. Michael Menth
> > > >University of Tuebingen
> > > >Faculty of Science
> > > >Department of Computer Science
> > > >Chair of Communication Networks
> > > >Sand 13, 72076 Tuebingen, Germany
> > > >phone: (+49)-7071/29-70505
> > > >fax: (+49)-7071/29-5220
> > > >mailto:[email-masked]
> > > >http://www-kn.informatik.uni-tuebingen.de
> > >
> > > ________________________________________________________________
> > > Bob Briscoe,                                BT Innovate & Design
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Wed, 4 May 2011 15:13:27 +0100

Toby

Sorry, i didnt follow all the previous thread. I know there was some discussion on somewhat peripheral issues (from an encoding perspective - as in emails below).
However, I cannot remember the conclusion on the substantial issue, ie what encoding or encodings we want to end up as standardised. Is it:-

         +--------+----------------------------------------------------+
         |        |           Codepoint in ECN field of IP header      |
         |  DSCP  |               <RFC3168 codepoint name>             |
         |        +--------------+-------------+-------------+---------+
         |        | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
         +--------+--------------+-------------+-------------+---------+
         | DSCP n |    Not-PCN   |      NM     |     ThM     |   ETM   |
         +--------+--------------+-------------+-------------+---------+

Or, in the case of single marking:

         +--------+----------------------------------------------------+
         |        |           Codepoint in ECN field of IP header      |
         |  DSCP  |               <RFC3168 codepoint name>             |
         |        +--------------+-------------+-------------+---------+
         |        | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
         +--------+--------------+-------------+-------------+---------+
         | DSCP n |    Not-PCN   |      NM     |     illegal |   PM    |
         +--------+--------------+-------------+-------------+---------+

Note that 01 = EXP doesn't appear.
Is this correct?
Thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Toby Moncaster
Sent: 04 May 2011 10:23
To: Briscoe,RJ,Bob,DES8 R
Cc: [email-masked]
Subject: [PCN] Revised 3-in-1 draft and status of RFC5696

Toby

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 4 May 2011 16:02:14 +0100

> From: [email-masked] [mailto:[email-masked]]
> Sent: 04 May 2011 15:13
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] Revised 3-in-1 draft and status of RFC5696
> 
> Toby
> 
> Sorry, i didnt follow all the previous thread. I know there was some
> discussion on somewhat peripheral issues (from an encoding perspective
> - as in emails below).
> However, I cannot remember the conclusion on the substantial issue, ie
> what encoding or encodings we want to end up as standardised. Is it:-
> 

That looks right

That seems right. In theory you could treat the "illegal" case as PM as
well... In fact, I would probably put it in with a warning something like

"In the basic encoding, the 01 codepoint is illegal and should only appear
if a PCN node is misconfigured. It is reasonable for the PCN-egress-node to
treat the 
01 codepoint as indicating PM in the same manner as 11, but it SHOULD raise
a management alarm."

> Note that 01 = EXP doesn't appear.

Indeed, and that was my suggested bis to RFC5696.

It looks like we are going to have to create a completely new combined
document after all. Certainly that is the cleanest option and allows us to
remove any confusions. It might take another complete cycle to do it though
which is not ideal :(

In order to handle the two distinct cases you set out above I would suggest
that such a document has two parts: a basic encoding (for single marking
schemes) and a full encoding (for dual marking schemes). This would make the
choice of encoding a configuration option similar to the option of whether
to turn on the two marking schemes or not. 

Question - would this require any changes to any other documents?

Toby

> > > > >>>>             ,--------.
> ,--
> > > > >>>>            '---------'
> '--

---

From: <[email-masked]>
Date: Wed, 4 May 2011 17:16:37 +0100

Toby said:
document after all. 
...

[phil]
I don't know whether a completely new combined doc is the best way. Maybe the RFC editor can advise?
(an alternative might be to update the baseline so it just applied to single marking (with EXP essentially deprecated) plus a new doc on 3-in-1, or to update the baseline with changes so that it includes both (ie defines EXP as per 3-in-1 or as deprecated). Anyway, this seems "just" a process question.

If it is a single doc, then the doc would split into 2 sections, with parallel sub-sections (encoding, applicability, allowed transitions).

I don't understand your comment about marking schemes (rfc5670 defines one Metering behaviour, the marking section of that doc says "   A PCN-packet MUST be marked to reflect the metering results by
   setting its encoding state appropriately, as specified by the
   specific encoding scheme that applies in the PCN-domain."

Which docs affected?
>From technical point of view, I think all are ok. Edge behaviours basically unaffected - clearly SM & CL refer to teh right sections

RFC 5670 is unaffected, i think. There is one point only where there might need to be thought -in section B.2 of rfc5670 (an Informative appendix on Implementation Notes) (I think the wording of the new doc should allow the text here still to be valid - anyway, the point is extremely pedantic)

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 21 May 2011 12:39:46 +0100

I have now released the revised version of the 3-in-1 draft.

After much thinking and pondering I reckon the only sensible thing regarding
RFC5696 is to revise it (rather than deprecating it). There are two reasons
for this, firstly the 3-in-1 encoding doesn't necessarily provide the
cleanest approach for a single marking scheme (since it fixes which marker
marks 01 and 11) and secondly there is still a desire among some to leave
alternative encodings open.

There are two routes to revising the document:

(A) Changing it to a single-marking encoding but keep it as a standard. That
requires:
 - deprecate the EXP encoding
 - remove the more irrelevant appendixes, and move the others into a -06
version of 3-in-1 (for instance all the discussion of which DSCP to use).

(B) Change it to an experimental encoding but tighten the rules about it not
being allowed in any other PCN-domain (in other words put the onus on
experimenters to be careful). That requires:
 - update the rules on experimental schemes
 - Add relevant warning text and re-word it to be clear this is only for
experiments
 - Move the DSCP related appendix to the 3-in-1 document

Of the two options (A) is relatively easy and would be my preference. (B)
requires lots of work and I would want a really convincing argument that
schemes such as PSDM are of interest to an operator before we went down that
route. In either case we are going to have to do some more work on 3-in-1,
but hopefully mainly cut-and-paste...

If I get another burst of energy today I may release a suggested draft for
option (A)...

Toby

> Sent: 04 May 2011 17:17
> (an alternative might be to update the baseline so it just applied to
> single marking (with EXP essentially deprecated) plus a new doc on 3-
> in-1, or to update the baseline with changes so that it includes both
> (ie defines EXP as per 3-in-1 or as deprecated). Anyway, this seems
> "just" a process question.
> 
> If it is a single doc, then the doc would split into 2 sections, with
> parallel sub-sections (encoding, applicability, allowed transitions).
> 
> I don't understand your comment about marking schemes (rfc5670 defines
> one Metering behaviour, the marking section of that doc says "   A PCN-
> packet MUST be marked to reflect the metering results by
> From technical point of view, I think all are ok. Edge behaviours
> basically unaffected - clearly SM & CL refer to teh right sections
> 
> RFC 5670 is unaffected, i think. There is one point only where there
> might need to be thought -in section B.2 of rfc5670 (an Informative
> appendix on Implementation Notes) (I think the wording of the new doc
> should allow the text here still to be valid - anyway, the point is
> extremely pedantic)

---

From: <[email-masked]>
Date: Wed, 25 May 2011 09:05:29 +0200

Hi Toby,

Single Marking is fine with me, if it is just single marking. That seems to be option (A) then.

I like PSDM in the flavour proposed by Michael (and me) lately:

http://tools.ietf.org/html/draft-menth-pcn-marked-signaling-ac

I think the proposal is an additional edge behaviour rather than an additional marking scheme.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Toby Moncaster
Sent: Saturday, May 21, 2011 1:40 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Revised 3-in-1 draft and status of RFC5696

Toby