Subject: Re: [PCN] Some comments on draft-ietf-pcn-baseline-encoding-02

From: <[email-masked]>
Date: Tue, 5 May 2009 10:40:45 +0100

Hi Gorry,
 
here is your list of comments with my annotations of how I addressed them in version 03 (the current version which is in WGLC). My comments marked {TM}...
 
Toby

________________________________

From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Fri 27/03/2009 18:20
To: [email-masked]
Cc: Briscoe,RJ,Bob,CXR9 R; Moncaster,T,Toby,CXR9 R; [email-masked]; Gorry
Subject: Some comments on draft-ietf-pcn-baseline-encoding-02

Here are some comments on pcn baseline encoding, the document seems in
good shape, but there are probably a few things I would update to help
others to read this document.

Gorry

General comments:

- It would be really nice to see the explanation.

{TM} this coment really applies to lots of the drafts. We have now concocted a new Intro paragraph (elevator pitch) to set the scene + I re-wrote the abstract (see later)

- I had problems reading this to understand what was the implication on
packet forwarding - the key thing that I thought was missing, I later
found in 4.2. Have the authors thought about placing this section ahead
of the others and then explicitly calling out with a [very short]
subsection on what to do if there were a DSCP conflict and how the
original traffic could be mapped to not-PCN and the where to find
details on how to traffic ECN-enabled traffic on this DSCP (i.e. tunnel?).

{TM}I still need to write a sub-section to address this, but am not sure where it should fit in the structure. Probably within 4.3 or as a new subsection 4.3.1. I can then refer to it in the intro...

- I found Table 2 hard to understand, then discovered there were some
encodings missing.

{TM} Completely replaced with text sections for ingress and egress + a new table for the interior nodes. Let me know if this is any clearer (not sure how else to clarify it as there are so many posisble transitions)

- I think the security considerations could be improved.

{TM} Did my best but they are still not ideal. Any suggestions on additions gratefully received!

- To me, Appendix A.2 seems reasonable.

----------------------
Specific comments:

Abstract
-  English seems to me to need a little polishing.
s/in order// ?
- Please mention ECN code points in the abstract.
- Later you say a sentence such as:
    The PCN encoding states are defined using a combination of the DSCP
    and ECN fields within the IP header. The baseline PCN encoding
    closely follows the semantics of ECN [RFC3168].

{TM} re-wrote abstract completely. Let me know if you think it is better or not

Abstract
" below the physical link rate." - This seems very odd to me, I thought
this was about the link capacity.

{TM} I think its about link rate but this is more to do with the architecture and marking behaviour. The new intro which has been agreed by most people uses rate not capacity...

Abstract
"states but such schemes will be described in other documents."
        ^
- insert comma, or better still separate this into two sentences (to me
it seems an odd way for a PS abstract to finish).

S1
Makes no mention of ECN fields, which would be nice for people wanting
to look for documents that show the meaning of the ECN-field.

{TM} It now mentions ECN

S1
"Other extensions have also been suggested all of which can build on the
baseline encoding."
- Seems very bold. is the WG sure that *ALL* can build on this?

{TM} removed claim and replaced with "can be easily extended" plus pointed out the guidelines later in doc (but no xref)

S1
"MUST extend this baseline scheme"
- How? - The draft places a normative requirement, but doesn't say what
is intended. Is this by updating this specification? By obsoleting this
spec? using some common part of the same framework? - I don't see what
is being required.

{TM} removed this

S3, bullet 2
    o  PCN-marked - codepoint indicating packets that have been marked at
       a PCN-interior-node using some PCN marking behaviour
       [pcn-marking-behaviour].  Also PM.
                                 ^^^^^^^
- is this an alternative or a definition of the term PN?

{TM} its the official abbreviation. I've clarified all these definitions

S3:
    o  Not-marked - codepoint indicating packets that are PCN-capable but
                                                                     ^
- comma?
S3:
       are not PCN-marked.  Also NM.
                             ^^^^^^^
- is this an alternative or, as I think, a definition of the term NM?

S3:
   By definition packets carrying such codepoints are PCN-packets.
                ^
- comma?

S3:
    o  PCN-compatible Diffserv codepoint - a Diffserv codepoint for which
       the ECN field is used to carry PCN markings rather than [RFC3168]
       markings.
- Could this definition be placed as bullet one or bullet two?

{TM} re-ordered all the definitions...

S3:
    In addition the document uses the terminology defined in [pcn-arch].
               ^
- comma?

S4:
    allows for traffic that is not PCN capable to be marked as such (Not-
    PCN).
- I'd like to see this more clearly called out. The reader of this spec
may be trying to figure out how these codepoints are used with PCN and
how to transport the traditional use of ECN or where the DSCP is already
used for non PCN traffic. The structure of the document did not really
help me in this case at all (although the framework seems to be
addressing this case). A very short section that simply sets out the NON-PCN

{TM} This probably still needs to be addressed. If I add a section as asked for above on DSCPs this would naturally sit there. But not sure where best to insert the section?

S4
            to prevent any possible future compatability issues.
- remove /any/ - or are sure?

{TM} I was fairly sure but I removed it anyway

S4
    o  Any packet that is not PCN-enabled (Not-PCN) but which shares the
                                                    ^

S4
Table 2 is not easily understood. In fact, I got pretty confused, then
discovered there were some encodings missing. I'd really like to see all
the encodings or a different table format.

{TM} see comment above

S4
       packet MUST be treated as if it were NM.
                                      ^^^^^^
- as if it carried the NM marking?

{TM} yep

S4
End 4.0 has a truncated sentence

{TM} Ooops! Don't know what happened there. Over-enthusiastic use of delete key

4.1 says:
If the packet is being tunneled then only the 11 codepoint gets copied
into the inner header upon decapsulation.

- This language seems odd to me.

{TM} rephrased this to hopefully make it clearer - and people will have to read Bob's ECN tunnel draft (which is much clearer in its new form) to find out more

An additional constraint is the need to minimise
    the use of DiffServ codepoints as
                                   ^^
-English? - because?

{TM} sorry,  missed this one...

S4.1
    The encoding scheme above seems to meet all these constraints and
- is this WG consensus, or author's?

{TM} I think its more or less WG consensus by now... It took a lot of arguing to get to this scheme and many dead ends...

S4.2
    Enabling PCN for a DSCP switches on PCN marking behaviour for packets
                       ^^^^^^^^^^^^^
- Better phrase here?

{TM} I've tried to improve the phrasing

S4.2
    but only if those packets also have their ECN field
    set to indicate a codepoint other than Not-PCN.
- presumably this refers to PCN router behaviour within a PCN domain?

{TM} Yes. Probably I should add this is only relevant within the PCN-domain

S4.2
    Enabling PCN marking behaviour disables any other marking behaviour
- OK, but I think this should be clearer that this is for only for a
specific DSCP.

{TM} missed this one

S5
    o  The 00 codepoint in the ECN field MUST mean Not-PCN.
- not sure /mean/ is the correct word, should it be /indicate/ (and
following points)
- and should this also say and /MUST NOT be  changed to any other
codepoint within a PCN domain/?

{TM} Yes - and now does say this. Also corrected to indicate

S5
    o  Once set the 11 codepoint in the ECN field MUST NOT be changed to
              ^
- insert comma
- /doesn't/ change to /does not/

S5
    o  Any experimental scheme MUST include details of all valid and
       invalid codepoint transitions at any PCN nodes.
- OK, you could say it MUST NOT update 00 or 11  (or is this now implicit?)

{TM} added. Hopefully everyone agrees with this...

S8
    Packets claim entitlement to be PCN marked by carrying a PCN-
- English? I think the document should say that that a PCN domain has
been pre-configured with domain edges, and that this document describes
behaviour within the domain.

{TM} I re-wrote section 8. Can you look and see if you htink I addressed most of these comments?

S8
   However there is a
    requirement to keep inter-domain scenarios in mind when defining the
    PCN encoding.
- I found this rather vague, or more precisely too vague for me to
understand the implications.

S8
   Then any one domain's security against its neighbours would
    be described as part of the proposed edge-node behaviour document.
- I could not understand what the security implication was and what was
being requested of people who followed this document with new proposals.

{TM} On re-reading I found this unhelpful so I removed and changed it

S9
    It also allows for the co-
    existence of competing traffic within the same DSCP so long as that
    traffic doesn't require end-to-end ECN support.
s/doesn't/does not/
- This sounds categorical that this is not possible, but presumably
tunnels may be used. Is theer better language that could be chosen?

{TM} I missed this one. I shoudl probably clarify that ECN can be tunneled but that it is effectively disabled within the PCN-domain.

S11
- Should be removed by RFC-Ed?

{TM} yes

S12: Refs.
- Are there no normative architecture specifications to define what PCN
is? - Seems odd for a PS, could this be [pcn-arch].

{TM} indeed it does seem odd but that is what the charter states. I think it is sort of trying to follow the lead of DiffServ where the architecture is an informational document. I have tried to refer to marking behaviour more often as that is standards track

S12: Refs.
- Why is RFC3168 also not normative?

A.1
  domain includes lower speed links
                 ^^^^^^^^^^^^^^^^^^
- Is this really the issue???  Or does this describe a PCN network link
with a link with low flow aggregation as an example of the case where
other appropriate use is needed. If this is not the case, we should
quantify what is meant by "lower speed" and be much more clear about the
guidance here. Either way, I find this confusing.

{TM} I have left this as is. Can others comment on whether they find this confusing also? It might almost be easier just to remove this section altogether

- A.1, suggests there is no fixed DSCP for PCN, this seems a pity from
the point of view of a router knowing whether PCN is to be invoked, it
therefore becomes yet one more thing that could be misconfigured. I
presume this decision has been extensively discussed within the PCN WG,
so this probably does not need action?

{TM} This follows advice from the ADs concerning how slow it is to get a standards track DSCP assigned. I believe the hope is that PCN will be rolled out by 1 or 2 operators and found to be successful. We can then come back and try for a complete set of DSCPs. Also this baseline encoding is a slight red herring as it is really just an enabler for experiments to see which alternative encoding is most sensible (and to see if encodings offering more codepoints are actually necessary). Current simulation results suggest schemes with a single marked state are less good than those with 2 marked states

A.2
    o  Leakage of traffic into PCN-domain: ECT(1) is less often correct.
- This does not make seem to make sense.

{TM} can't remember why we worked that out but it seemed to make sense at the time... However I have tried to re-phrase this

    o  Leakage of traffic out of PCN-domainL Either ECT is equally unsafe
                                           ^
- Character? /./

A.2
    o  Incremental deployment: Either ECT is suitable as long as they are
                                         ^           ^^^^^^^^^^^^^^^^
- Please insert /codepoint/ and s/as long as/, providing that the
codepoints are/

Editorial question should it be "PCN capable" or "PCN-capable"?

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 05 May 2009 18:49:34 +0200

Greetings Toby!

Thanks, I was pleased to see many of the comments had been addressed.
There are some comments that you may like to consider further as you
process any other LC comments (marked **).

I hope this helps, this document seems quite mature and looks nearly
finished.

Best wishes,

Gorry

[email-masked] wrote:
> {TM} this comment really applies to lots of the drafts. 
> We have now concocted a new Intro paragraph (elevator pitch)
> to set the scene + I re-wrote the abstract (see later)
> 
True. I found the new abstract is much clearer, if i had read this
and the new introduction I do not think that I would have made that comment.

> {TM}I still need to write a sub-section to address this, but am not 
> sure where it should fit in the structure. Probably within 4.3 or as a
> new subsection 4.3.1. I can then refer to it in the intro...
> 

> {TM} Completely replaced with text sections for ingress and egress 
> + a new table for the interior nodes.
> Let me know if this is any clearer (not sure how else to clarify
> it as there are so many posisble transitions)
> 
Looks good.

> {TM} Did my best but they are still not ideal. 
> Any suggestions on additions gratefully received!
> 
** This point seems weak:
    "o  Leakage of traffic into PCN-domain: ECT(1) is slightly less likely"

I think you should be stronger e.g.:
"Overall this seemed to suggest ECT(0) was most appropriate to use."
- e.g. On the basis of the above considerations, ECT(0) was selected for
use.

> {TM} I think its about link rate but this is more to do with the architecture
> and marking behaviour. The new intro which has been agreed by most 
> people
> uses rate not capacity...
> 
> Abstract
The rewrite looks good to me.

> to look for documents that show the meaning of the ECN-field.
** Good, although a NIT is it would be nice to see the term "ECN"
defined (expanded) the first time it appears in the introduction.

> {TM} removed claim and replaced with "can be easily extended" plus 
> pointed out the guidelines later in doc (but no xref)
> 
** NiT: I misread /states and rules/ when I first read this, perhaps you
could put some punctuation in here?
e.g.
/However, the encoding can be easily extended to provide more
    states. Rules for such extensions are given in this document./

> spec? using some common part of the same framework? - I don't see what
OK - that avoids this issue.

> {TM} re-ordered all the definitions...
Fine now.

> {TM} This probably still needs to be addressed. If I add a section as 
> asked for above on DSCPs this would naturally sit there. But not sure 
where
> best to insert the section?
>
** This question still seems to need an answer.
> {TM} I was fairly sure but I removed it anyway
done.
> {TM} rephrased this to hopefully make it clearer 
> - and people will have to read Bob's ECN tunnel draft (which is much
> clearer in its new form) to find out more
> 
> 
** Please fix

> - is this WG consensus, or author's?
** Seems fine, then I'd be happier making this decision and saying "This
was judged by the PCN WG to ..."
> 
> {TM} I think its more or less WG consensus by now... 
> It took a lot of arguing to get to this scheme and many dead ends...
> 
> S4.2
OK
> {TM} Yes. Probably I should add this is only relevant within the PCN-domain
** I think your proposed change would be an improvement.

> - OK, but I think this should be clearer that this is for only for a
** I think this should be changed.
> {TM} Yes - and now does say this. Also corrected to indicate
OK
> {TM} I re-wrote section 8. Can you look and see if you think I addressed
> most of these comments?
> 
Better

> understand the implications.
Fixed.
> {TM} On re-reading I found this unhelpful so I removed and changed it
OK

> tunnels may be used. Is there better language that could be chosen?
> 
> {TM} I missed this one. I should probably clarify that ECN can be 
> tunneled but that it is effectively disabled within the PCN-domain.
> 
** Not sure I understand what you propose that the new text would say. I
think that ECN markings may be tunneled across an ECN domain, by
encapsulating an IP packet with a tunnel header. How would the outer
header of the tunnel be treated if the tunnel egress endpoint was
outside the PCN domain?

** Section 8 also describes behaviour when IPsec is used to tunnel PCN
marked packets.

> - Should be removed by RFC-Ed?
Done.
> {TM} indeed it does seem odd but that is what the charter states. 
> I think it is sort of trying to follow the lead of DiffServ where the
> architecture is an informational document. I have tried to refer to
> marking behaviour more often as that is standards track.
> 
Seems to be addressed.

> - Why is RFC3168 also not normative?
done.
> {TM} I have left this as is. Can others comment on whether they find
> this confusing also? It might almost be easier just to remove this
> section altogether>
>
The new text seems better.

** The terms "higher" and "lower" are comparative terms, and am I right
that here it relates to the ratio between the rates of the admitted
flows and the link rate (i.e. level of statistical multipelxing)?

> {TM} This follows advice from the ADs concerning how slow it is to 
> get a standards track DSCP assigned. I believe the hope is that PCN
> will be rolled out by 1 or 2 operators and found to be successful.
> We can then come back and try for a complete set of DSCPs.
> Also this baseline encoding is a slight red herring as it is really
> just an enabler for experiments to see which alternative encoding is
> most sensible (and to see if encodings offering more codepoints are
> actually necessary). Current simulation results suggest schemes with
> a single marked state are less good than those with 2 marked states
> 
Understood, and I assume the ADs would support this. See comment at end.

> {TM} can't remember why we worked that out but it seemed to make sense at
> the time... However I have tried to re-phrase this.
>
** Not sure this really answers the question. You seem already to have
reasons, if you can not clarify this, could you consider omitting it?

>     o  Leakage of traffic out of PCN-domainL Either ECT is equally unsafe
done.
>     o  Incremental deployment: Either ECT is suitable as long as they are
done.
> Editorial question should it be "PCN capable" or "PCN-capable"?
done.

** New nits:

Please change /any otehr/ to /any other/
and in abstract: /t o/ to /to/.

S4:
/      codepoint as PCN-enabled traffic MUST have the ECN field equal to
       00./
- This relates to the outer IP header, right?

S4.3:
/   Equipment complying with the baseline PCN encoding MUST allow PCN to
    be enabled for certain Diffserv codepoints. /
- I understand this, but if this is a requirement, I should have noted
that "certain" is probably not sufficient for a manufacturer to claim
compliance. Would it be compliant if the manufacturer supported this
only one DSCP value - and if so is there any interoperability between
different vendors. Maybe I am wrong, but I would expect manufacturers to
allow configuration of these codepoints from a a range of required
codepoints?

I observe you use both the keywords: MUST and SHALL, it is worth
checking these are consistently used - or consider changing all MUST to
SHALL.

Last, at the end of section 6 you write:
" It
    should be noted that this baseline encoding effectively disables end-
    to-end ECN except where mechanisms are put in place to tunnel such
    traffic across the PCN-domain."

- I udnerstand this, but if I was reading this as someone wanting to
preserve  normal ECN semantics, I am not sure I would clearly see what
would  happen.

If I setup a tunnel across the DS domain, then the tunneled
packets ECN behaviour would be preserved, right? However, within the PCN
domain then I would see a different ECN behaviour, which would be ...

End.