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

[<[e-mail]>]

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