RE: [PCN] Consensus call: movingdraft-chan-pcn-encoding-comparison-00 to working group document

["Kwok-Ho Chan" <[e-mail]>]

Phil, Bruce, all:
Thank you very much for the suggestions.
They are inline with the direction I was heading on simplifying the 
original pre-00 draft.
With the received support on continuing the simplification direction.
I am currently rewriting most of the draft.  Removing much of the extras.
Thanks!
-- Kwok --

At 11:31 AM 8/14/2007, [e-mail] wrote:
>I thought about this more (101 uses for boring meetings).
>
>For the I-D I suggest:
>Part A: lists the encodings
>Part B: discusses pros and cons of them
>
>Part A, I entirely agree with the approach that Bruce suggests below, ie
>draft just says various approaches require 2, 3 (& 4?) codepoints
>(PCN-marked, unmarked; etc), and for each then list encoding options
>(DSCP-1, DSCP-2 OR ECN-'11', ECN-'00'; etc). I'd stick here to simply
>how many codepoints the PCN mechanism itself requires; there are some
>specific encodings that actually under a given set of scenario
>assumptions need more codepoints, but I'd deal with that under Part B as
>a disadvantage.
>
>
>Part B
>I think this nicely divides into 'issues for encodings that use dscp
>field' and 'issues for encodings that use ecn field'. Encodings that use
>both get both sets of issues [if it's more complicated than that,
>consider later in detail, basically a second order issue]
>
>For encodings that uses DSCP field:
>1. interactions with multiple PCN classes. Ie if there are n PCN
>classes, you need n times as many codepoints (=dscps). Because PCN-nodes
>use DSCPs to distinguish PCN classes. This is a particular issue for
>operating PCN in an MPLS network, where you have less codepoint space
>(same argument probably applies to PCN on other networks eg Ethernet?).
>one option is simply to insist that there's only 1 pcn class (nb not
>what the architecture draft says).
>2. interactions with ECMP. ECMP algos can use a packet's DSCP when
>deciding what interface to fwd it on. In a PCN-domain running ECMP, for
>a flow which has some packets PCN-marked and some unmarked. its packets
>will travel over more than one path. This may well lead to mis-ordering.
>ug. Maybe some more complicated interactions, esp if there are multiple
>pre-congested nodes... not sure.
>3. maybe something about dscps being quite lightly standardised -
>limited rules on how you use them, largely up to the operator.
>4. interactions with RFC4794 use of ecn field. None.
>
>For encodings that use ECN field:
>1. interactions with ECMP. None. ECMP algos don't use a packet's ECN
>field when deciding what interface to fwd it on
>2. interactions with multiple PCN classes. None. Doesn't change the
>number of codepoints needed.
>
>in the bullets below, '(un)planned' isn't quite the right word. I'm
>trying to distinguish between cases where everything is behaving
>correctly and cases where something is misconfigured or something else
>has gone wrong.
>3. 'planned' interactions with CE (ie a pkt arrives, in a PCN class, at
>PCN-ingress-node with CE). The architecture draft (S3.5) has some text
>on how this is handled (basically, the default option is just to drop
>the pkt).
>4. 'planned' interactions with ECT (ie a pkt arrives at PCN-ingress-node
>with ECT-1 or ECT-0). Probably best to forward the pkt (effectively
>re-set to '00'), or else drop as per CE pkts?
>5. 'unplanned' interactions with ECN. These are some of the things said
>or suggested in [RFC4774], I think the 3 main categories are:
>- a RFC4774 pkt gets accidentally dscp-re-marked to the pcn-dscp; a
>PCN-ingress-node gets misconfigured so it allows a RFC4774 pkt in on the
>pcn-dscp. Can anything nasty happen?
>- a router in the PCN-domain misconfigures itself so it's
>RFC3246-enabled (ie no longer PCN-enabled). Can anything nasty happen,
>eg when PCN-marked pkts encounter this router?
>- a PCN-egress-node gets misconfigured so it allows a pcn-marked pkt
>'out' of the PCN-domain.
>this section is a bit trickier to think about; it needs a short para on
>each possible misconfiguration scenario to explain what the (potential)
>issue is; they're definitely not equally important. Also, we should make
>sure the discussion is confined to ecn-pcn interactions (I have a
>feeling it would be easy to get side-tracked into wider misconfiguration
>issues that have nothing to do with encoding choice)
>
>
>there are a few very detailed issues (eg in S11.6.4 & 11.6.5 of
>draft-briscoe-tsvwg-cl-phb-03, but we can ignore for now I think)
>
>anyway, I think the whole thing could be done in a nice short draft (5
>pages of real text?)
>
>best wishes,
>phil/
> > -----Original Message-----
> > From: Bruce Davie [mailto:[e-mail]]
> > Sent: 27 July 2007 18:05
> > To: Steven Blake
> > Cc: pcn
> > Subject: Re: [PCN] Consensus call: movingdraft-chan-pcn-encoding-
> > comparison-00 to working group document
> >
> > I think the draft needs so much revision at this point that I would
> > rather wait for the next version before deciding if it is ready to be
> > a WG document.
> >
> > Specifically, the draft needs to avoid replicating so much material
> > from other sources. Almost everything in sections 1 and 2 should be
> > removed. The place to define or discuss PCN motivation, terminology,
> > architecture, etc., is in other drafts (such as the architecture
> > draft). This draft should only reference other drafts. If the authors
> > think they need some new terminology, I would urge them to get the
> > architecture team to include it in their draft.
> >
> > This draft should consist of statements like "The approach to PCN
> > described in [Reference] requires N distinct packet markings
> > (codepoints). These codepoints could be encoded in the following ways:
> >    - encoding A
> >    - encoding B
> >
> > etc.
> >
> > And then discuss the tradeoffs among the different encoding
>approaches.
> >
> > The authors should be careful to distinguish between the state of a
> > *node* and a marking of a *packet* (e.g. a node might be in a
> > severely congested state, in which case it wants to be terminating
> > some flows, leading to some marking of packets with a "terminate"
> > marking. But note that a node will often generate several different
> > markings while in a given state, hence states and markings are not
> > equivalent.) I think the attempt to make this distinction was what
> > led to the notion of "features" which most people (including me)
> > seemed to find confusing.
> >
> > This looks like a pretty major rewrite to me.
> >
> > Bruce
> >
> > On Jul 27, 2007, at 10:25 AM, Steven Blake wrote:
> >
> > > PCN,
> > >
> > > During the Chicago PCN meeting, the authors of
> > > draft-chan-pcn-encoding-comparison-00 asked that this draft become a
> > > working group document.  Based on the discussion in the room, the
>PCN
> > > chairs determined that there was no consensus amongst the meeting
> > > participants to move this version of the draft to a working group
> > > document at this time.  There was a comment made that if certain
> > > simplifications were made in the next version of the draft (e.g.,
> > > reducing the amount of text on marking semantics and concentrating
>on
> > > syntax), then the draft then would be ready to move to working group
> > > document.  The chairs asked the authors to consider this approach.
> > > More
> > > details of the discussion will be available when the meeting
> > > minutes are
> > > posted.
> > >
> > > This email is a request for comments on moving
> > > draft-chan-pcn-encoding-comparison-00 to working group document.
> > > Please
> > > send your comments to the list within the next week.
> > >
> > >
> > > Scott & Steve
> > >
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > Steven Blake                <[e-mail]>
> > > Ericsson/Redback Networks               [phone]
> > >
> > >
> > >
> > > _______________________________________________
> > > PCN mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/pcn
> >
> >
> > _______________________________________________
> > PCN mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/pcn
>
>
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/pcn



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