RE: [PCN] Fwd: I-D Action:draft-chan-pcn-encoding-comparison-01.txt

Hi Phil

Thanks for your comments!

Please see in line!

Best regards,
Georgios

On 11/20/2007, "philip.eardley@bt.com" <philip.eardley@bt.com> wrote:

>Kwok, Georgios, all,
>
>Here are some comments on this draft
>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-0
>1.txt - it's much better than 00!
>Sorry for the lengthy email
>Thanks,
>Phil/
>
>1. Introduction
>Good.
>
>2. Encoding requirements
>First 2 paras good.
>last para /bullets can be improved & I do not agree with "A total of six
>required encoding states". Suggested replacement:
><<
>Different PCN-marking behaviour documents have suggested different
>encoding states are needed (2, 3 or 4 of the ones below). In total, the
>following possibilities have been suggested:
>
>o Not pre-congested Marking, for indication of No pre-Congestion
>o Admission Marking, for indication of Flow Admission Information
>o Termination Marking, for indication of Flow Termination Information
>o Single Marking, for indication of pre-congestion Information
>o Affected Marking, also for indication of Flow Termination Information
>
>In addition there must be a way of distinguishing PCN-packets (whether
>PCN-marked or not) from non PCN-pkts.
>
>NOTE:
>o Single Marking: this has been suggested by [ref]. a single marking is
>used to indicate both admission and termination marking
>o Affected Marking: this has been suggested by [ref]. Its suggestion is
>that a PCN-node which is termin-marking some pkts (ie is in the
>termin-marking state) encodes the rest of the PCN-pkts with the affected
>marking.
>o the WG will select which of the 5 possible encoding states listed
>will actually be supported, or if the choice is a deployment choice for
>the operator or under the control of an OAM Configuration system option
>(eg where an operator employs either adm-marking or termin-marking but
>not both in the PCN-domain).
>>>

Georgios: Agree with the above, except that Single Marking is vague,
since it could have different meaning for different situations. Insome
situations is used to identify AM and/or TM and in others is used to
identify AM and/or TM and a way to distinguish PCn packets from non
PCN-pkts.
But if the PCN WG is willing to include SM
is okay for me!

>
>a few words about the above.
>I think have to talk about single marking - calling it AM/TM in the
>tables is confusing (for me).
>I think it's better to say there has to be a way of distinguishing
>PCN-packets & non PCN-pkts, rather than saying there has to be an extra
>encoding state.
>I don't think nonce cheater detection is relevant [I think you're
>talking about ECN nonce. It's fair enough to talk at the appropriate
>moments about loss of ECN info if the ECN field is used to encode PCN.
>but I think it's confusing (and on occasions, in some of your encoding
>tables, wrong] to list ECN nonce as a PCN encoding state. Or are you
>suggesting a *PCN* nonce? (would seem this isn't needed, as PCN-domain
>is trusted. However, maybe thinking about future extensions?)

Georgios: The ECN nonce discussion is associated with Section 4.3 in:
http://www.ietf.org/rfc/rfc4774.txt?number=4774
We have to clarify this in the text.

>
>New sub-section 2.2
>I wonder if it's worth introducing what will be the evaluation criteria,
>eg:
>How easy is it to support multiple PCN classes ?
>Are there any interactions with ecmp?
>Are there any interactions with ecn?
>Codepoint shortage for mpls.
>etc

Georgios: You are right, we had such criteria in the previous version,
but they were skipped during this version. I think is important to
include criteria!
Are these 4 enough?

>
>
>Section 3 Encoding options
>The first few lines (before bullets) could be shortened to:
>"There are various encoding options, which can be grouped by which
>fields they use:"
>You can add a note here that "using a different channel (e.g., IPFIX .."
>is out of scope of WG. I believe this is agreed. Section 3.4 can
>therefore be safely deleted.

Georgios: Agree!
>
>The list of abbreviations can be tweaked:
>Add:
>SM single marking ;
>Not-pc [or something meaning 'not pre-congested']
>
>Delete: Not-ce, NDS-CE

Georgios: The above can be applied if the PCN WG decides to use SM as
additional encoding state, see above.

>
>Section 3.1+
>Think the "ecn & dscp" [current 3.1] needs the most explanation, so I
>don't think it should be done first. suggest swapping with 3.3.

Georgios: Agree!

>
>3.1 ECN & DSCP:
>I found the first part of this [before 3.1.1] too dense. I think more
>options need to be listed. I think the terminology in the table is
>confusing, replace:
>-----------------------------------------------------------------------
>| ECN Bits || 00 | 01 | 10 | 11 || DSCP
>|
>|==============++==========+==========+==========+==========++==========
>|
>| RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA
>|
>|==============++==========+==========+==========+==========++==========
>|
>| Option 1 || AM | NA | NA | TM || PCN
>|
>|--------------++----------+----------+----------+----------++----------
>|
>| Option 2 || Not-PC | NA | NA | SM || PCN
>|
>|--------------++----------+----------+----------+----------++----------
>|
>| Option 3 || NA |Not-PC(A) | Not-PC(T)| SM || PCN
>|
>|--------------++----------+----------+----------+----------++----------
>|
>| Option 4 ......
> -----------------------------------------------------------------------
>

Georgios: I think that this can be replaced if the PCN WG decides to use
SM as an additional state.

>In Option 3 I tried to work out what you meant by ECT(A) & ECT(T). I
>think you're saying that the PCN-ingress-node sets the pkt with a mix of
>2 codepoints; and only Single Marking state is used to indicate
>pre-congestion; a pcn-node that wants to adm mark a pkt then selects a
>Not-PC(A) pkt and re-marks it to SM. Is that right? need to explain why
>this might be useful.

Georgios: We will clarify this, but please note that the option is taken
from:
http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-phb-03.txt
In particular see Alternative 2 from the above given draft.

>
>There was an option once mentioned [in a draft-briscoe-architecture I
>think] of using a 2nd DSCP to indicate TM (or perhaps to indicate
>Affected marking).

Georgios: Agree!

>
>I also think you can talk separately about the Affected marking. In my
>table, AFM can obviously be added to all 3 Options

Georgios: Agree!
>
>I also think there's a separate series of options where you're trying to
>preserve ECN information on an end-to-end basis whilst having PCN
>running in some domain in the middle. And you don't want to solve this
>by doing something else like tunnelling over the PCN-domain. I think
>this needs separate discussion as the issues are different and quite
>hard to think about. For instance, there are two separate cases: just
>preserving the Not-CE & CE info, and also preserving the ECT-nonce info
>[there are different levels of interest/deployment/standardisation].
>So I think it would be better to have a separate section discussing
>encoding options when ECN info needs to be preserved.

Georgios: Agree, but this is what we wanted to emphasize in Section
3.1.1.1!
We could provide a disussion on ECN tunelling though in an additional
section.
>
>
>3.1.1
>could expand with something like:
>For example, this means that PCN can easily be applied to multiple
>classes.

Georgios: Okay!

>
>3.1.1.1, [RFC4774] interactions:
>as well as the things you talk about, I thought [not sure though] that
>4774 was concerned about "what happens if things go wrong", eg:
>- 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.
>
>eg if the first case happens, may want to try to minimise the impact of
>any ECN-CE pkts that therefore sneak in on the PCN class

Georgios: I think that the issues that you mentioned are related to Issue
4 given in Section 3.1.1.1. This means that it will be good if we will
work out Issue 4. At the moment we avoid the discussion of this issue in
the draft.

>3.1.2
>"possibly adding complexity when tunneling of the PCN encoding is
>required" - explain.

Georgios: Agree!

>
>3.2 using ECN field
>if I understand this case right, you're saying that you're NOT using a
>different DSCP to distinguish PCN traffic from non-PCN traffic. Think
>you need to make this really clear, as it's quite bizarre. However, as
>draft-pcn-architecture says "There needs to be a way for a PCN-node to
>distinguish PCN-traffic from non PCN-traffic" - I don't understand how
>you propose to do this, although I could imagine an Option like this:
>|==============++==========+==========+==========+==========++==========
>|
>| Option 1 || Not-CE | Not-PC | SM | CE || NA
>|
>|--------------++----------+----------+----------+----------++----------
>|
>One downside of this is that there can only be 1 PCN class [PHB]
>
>basically I don't understand the table.

Georgios: We will clarify this, but please note that the option is taken
from:
http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-phb-03.txt
In particular see Alternative 2 and 5 from the above given draft.

>
>
>3.3 DSCP
>in table, I think you should change things like "PCN/AM/TM" to SM, eg:

Georgios: If the PCN WG decides to use SM as additional state then OKAY!

>-----------------------------------------------------------------------
>| DSCP Bits || Original |Experimental 1 |Experimental 2 |Experimental 3
>|
>|===========++==========+===============+===============+===============
>|
>| Option 7 || Not-PC | SM | NA | NA
>|
>|-----------++----------+---------------+---------------+---------------
>|
>
>3.3.1 Benefits
>" concerns raised in RFC 4774 [20] are not applicable" - pedantic point:
>I think it's really that they should be easier to deal with [whether or
>not they're applicable depends on whether a PCN-node knows how to
>process a pkt with the ECN field set]

Georgios: I do not understand your argumentation:
IF ECN is not used within the PCN domain then the requirements imposed by
RFC 4774 do not apply!

>
>" all 4 DSCP encoding options depicted in Figure 3 can support the not
>congested indication, PCN capable transport marking, the admission
>control and flow termination encoding states." Don't understand this,
>only true for options 9 & 10.
Georgios: Agree, needs editing!

>
>"In addition Option 8 and 10 can in addition support the ECMP solution."
>Replace: "They support Affected marking, which [ref] says has benefits
>if the PCN-domain operates ECMP multi-path routing"
>
>additional benefit (and in my view the most significant): exptal dscps
>are lightly standardised - limited rules on how you use them, largely up
>to the operator.

Georgios: Agree!

>
>3.3.2 Drawbacks
>clarify by replacing
>"This type of encoding needs to use per PHB, in addition to the original
>DSCP and depending on the encoding option used, one, two or three DSCP
>values, respectivelly."
>With "This type of encoding needs to use, for each DS class (PHB) that
>is PCN-enabled, 2 3 or 4 DSCP values, depending on the encoding option."
>
>Clarify that you need this set of 2/3/4 dscp values for each class
>that's PCN-enabled.

Georgios: Agree!
>
>Clarify that particular issue for mpls [codepoint shortage]

Georgios: Agree!
>
>"Furthermore, if the separation between the PCN traffic and non- PCN
>traffic is required". According to draft-pcn-architecture S4.5, there is
>no "if" about it.

Georgios: Agree!
>
>last para repeats what already said.

Georgios: Okay!
>
>Major disadvantage: 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.
>To me, this means that the S3.3 DSCP option is a non-starter in any
>PCN-domain that uses an ECMP algorithm that uses the DSCP. 

Georgios: well I do not see this as a disadvantage. However, what you
mention about having an ECMP algorithm that uses DSCP is relevant.
Thus what we can do is to include a sentence in that emphasizes that the
ECMP situation is solved only if the ECMP algorithm does not use DSCP
during the implementation of the equal cost multi path algorithm.

> NB ECMP algos
>are proprietary to router vendors, ie operator has poor control over
>them.

Georgios: I am not sure about the above! An operator could at least
disallow the ECN option.

>
>S3.4 out of band channel - section can be safely deleted.

georgios: Agree!
>
>S5 Security implications
>All these are I think covered by the draft-pcn-architecture, so can
>safely delete everything.

Georgios: Agree!

>
>Frequent Typo:
>None PCN capable => non PCN capable

Georgios: Okay!
>
>

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn