Subject: RE: [PCN] Fwd: I-D ACTION:draft-chan-pcn-encoding-comparison-00.txt

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 21 Jul 2007 06:17:16 +0000

On 7/20/2007, "Georgios Karagiannis" <[email-masked]> wrote:

>Hi Phil
>
>Thank you very much for the comments!
>Please see some remarks in line!
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: donderdag 19 juli 2007 12:12
>> To: [email-masked]; [email-masked]
>> Subject: RE: [PCN] Fwd: I-D
>> ACTION:draft-chan-pcn-encoding-comparison-00.txt
>>
>> Kwok, Georgios
>>
>> I read your draft. I have quite a lot of comments, but the
>> basic msg is that i think it's a suitable starting point for
>> a WG draft (towards the Charter milestone on this subject) - thanks.
>
Georgios: Thank you very much!

>>
>> 1. motivation & goals
>> this seems quite long for this draft, maybe the material is
>> more suitable elsewhere eg architecture draft?
>
Georgios: We will try to reduce the text!

>>
>> 2. PCN encoding .. in current PCN .. mechanisms & Appendix I
>> didn't find it useful to present the various proposed
>> mechanisms. The dependence between encoding & mechanism
>> (marking algo & PCN-boundary-node reaction) seem pretty weak
>> to me. In fact I think there's almost none, except in terms
>> of the number of codepoints that a proposed mechanism uses.
>> (Even this is not clear-cut; for example 'Affected marking'
>> could, I think, be easily added to those proposals that don't
>> mention it, or indeed removed from those proposals that do.)
>>
>> So can this section simply say that different proposals
>> require different numbers of encoding codepoints, and explain
>> this in a paragraph?
>
Georgios: Please note that this draft should be a survey.
Thus what we have done we have checked
the existing PCN like mechanisms and briefly described them.
In this way we could described which PCN features and which
encoding modes/states are supported(and thus are available) by these
mechanisms.
I would like to keep this section.

>>
>> Incidentally, I found it a bit confusing to describe "not
>> congested" as a feature - at least, it doesn't seem a feature
>> in the way that adm ctrl & flow termination are features. In
>> fact, I found the discussion of 'features' in S3 & 4 a bit
>> misleading (stick with codepoints).
>
Georgios: I think that a better term would be PCN encoding features,
instead
of PCN features.
In this case "not congested" admission control and flow termination can
be
seen to belong in the same category. What we actually wanted to do is to
emphaisze and differentiate between
PCN encoding features and encoding modes/states.
This is because one PCN encoding feature can be accomplished using more
than
one encoding modes/states

>>
>> I think phrases like "requirement for xx marking" could be
>> better expressed (are they reqts? It's a choice about how
>> many codepoints we
>> have)

Georgios: Do you have any suggestion on naming?

>>
>> 3. survey of encoding
>> the table is very useful.
>>
>> Would it be better grouping the options in terms of the
>> number of codepoints required? Ie if the mechanism needs 3
>> codepoints here are your options; if it needs 4 here they are etc.

Georgios: I am not sure if this will encounter what we wanted to do.
Please note that we intended to also include the PCN encoding features
that are supported by each option.

>> Should there be an option similar to option 9, but with PCN dscp?

>> Should there be an option similar to option 10/11, but with 2 DSCPs?
>> (that single marking mechanism could use)

Georgios: I do not understand this remarks. Maybe we can discuss them in
Chicago

>> Don't understand NDS-CE
Georgios: will clarify!

>>
>> There are many typos where 'none' should be 'non' (non PCN capable
>> transport)

Georgios: agree it is a typo!

>>
>> In option 2 (& 6, 7) what does ECT(A) & ECT(T) mean? (I
>> remember back in Briscoe-cl-phb we looked at an option where
>> PCN marking was signalled by a *change* of codepoint, maybe
>> it's referring to this idea? ie Adm marking is 01 -> 00 &
>> Termination marking is 10 -> 11.)

Georgios: yes this is taken from Briscoe-cl-phb draft.

>>
>> S3.4 use of IPFIX. I know you included this section because
>> the charter seems to suggest it - but I must admit to finding
>> it out of place in this doc.

Georgios: I think it is good to include an option that uses for encoding
and transport a different channel than the data path.

>>
>>
>> 4. comparison
>> I wonder if it's worth starting this section with all the
>> points that relate to how many codepoints there should be,
>> and later handle the more detailed aspects.
>>
>> Aspects of the first part:
>> - will there be non-PCN traffic in the DS network? (surely a
>> clear yes, ie we need a separate PCN DSCP(s))
>> - MPLS (which has limited codepoint space) [discussed in
>> earlier Briscoe-cl-architecture drafts - could adapt text from there]
>> - whether 'affected marking' is needed /useful [no consensus
>> at present
>> - based on your text in S2]
>> - whether adm ctrl & termination ctrl can be driven by the
>> same encoding

Georgios: Check and discuss the above issues in Chicago

>>
>> - perhaps that adm ctrl & flow termination mechanisms are not
>> required to both be deployed (just one could be)
>> - etc

Georgios: yes, but many scenarios require both ... Therefore is good to
emphasize which of them support both and which not!
>>
>> this would actually shorten some of the draft, eg S4.2.3
>> could basically disappear.
>>
>>
>> some of the ECN nonce discussion I found hard to follow
>> 4.1.5. explain what 'alternate ECN semantics' means
>> S4.2.5 I didn't follow what cases you were distinguishing.
>> there are a couple of issues at the high level: whether ECN
>> nonce is useful with PCN; backwards compatibility of PCN with
>> ECN nonce, eg in an 'unusual situation' such as the PCN pkt
>> encounters an 'old' (ECN) router.

Georgios: we have to update and enlarge section 4.2.5
>>
>> could mention the discussion we had about the charter
>> assuming a single domain, but we're going to keep strongly in
>> mind that want it to work multi-domain in future. This seems
>> esp important when it comes to encoding - after all, if it's
>> just your domain you can do what you like.
>> The multi-domain consideration has several impacts I think:
>> * makes standardising encoding important
>> * need to consider rfc4774 [because the issues it raises are
>> probably more significant in the inter-domain case than in
>> one domain under one operator's control]

georgios: Thus you propose to include the multi-domain support as an
additional criterion

>> * need to consider limitations about encoding from
>> draft-briscoe-re-pcn-border-cheat-00.txt [proposed mechanism
>> for making PCN work inter-domain]

Georgios: We will discuss this in CHicago

Best regards,
Georgios

>>
>> best wishes - see you in Chicago!
>> phil
>>
>> > -----Original Message-----
>> > From: Kwok-Ho Chan [mailto:[email-masked]]
>> > Sent: 05 July 2007 21:13
>> > To: [email-masked]
>> > Subject: [PCN] Fwd: I-D
>> ACTION:draft-chan-pcn-encoding-comparison-00.txt
>> >
>> > PCN WG:
>> > I would like to bring to your attention the availability of the
>> > initial version of PCN Encoding Comparison draft.
>> >
>> > Please review and comment.  And discuss on the PCN list.
>> >
>> > Thank you very much and looking forward to your comments.
>> > -- Kwok and Georgios --
>> >
>> > >To: [email-masked]
>> > >Cc:
>> > >From: [email-masked]
>> > >Date: Thu, 05 Jul 2007 13:15:02 -0400
>> > >X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
>> > >Subject: I-D ACTION:draft-chan-pcn-encoding-comparison-00.txt
>> > >X-BeenThere: [email-masked]
>> > >X-Mailman-Version: 2.1.5
>> > >Reply-To: [email-masked]
>> > >List-Id: i-d-announce.ietf.org
>> > >List-Unsubscribe:
>> <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>> > >  <mailto:[email-masked]?subject=unsubscribe>
>> > >List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>> > >List-Post: <mailto:[email-masked]>
>> > >List-Help: <mailto:[email-masked]?subject=help>
>> > >List-Subscribe:
>> <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>> > >  <mailto:[email-masked]?subject=subscribe>
>> > >X-Spam-Score: 2.3
>> > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on
>> > ecarhea1.nortel.com
>> > >X-Spam-Tests: FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106,
>> > >  NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1,URIBL_MANURI=1
>> > >X-DNSBL-Score: -50
>> > >X-DNSBL-Servers: bl.nortel.com
>> > >X-SMTP-HELO: megatron.ietf.org
>> > >X-SMTP-MAIL-FROM: [email-masked]
>> > >X-SMTP-RCPT-TO:
>> >
>> >[email-masked],[email-masked],[email-masked],bharr
>> ath@nortel
>> .c
>> >
>> om,[email-masked],[email-masked],[email-masked],hu
>> iwc@nortel
>> .c
>> >
>> om,[email-masked],[email-masked],[email-masked],kh
>> chan@norte
>> l.
>> > com
>> > >X-SMTP-PEER-INFO: megatron.ietf.ORG [156.154.16.145]
>> > >X-SMTP-REASON: PASSED
>> > >X-SMTP-ID: 1183656101.14019435
>> > >X-OriginalArrivalTime: 05 Jul 2007 17:21:42.0459 (UTC)
>> > >FILETIME=[F47A20B0:01C7BF28]
>> > >
>> > >A New Internet-Draft is available from the on-line Internet-Drafts
>> > >directories.
>> > >
>> > >
>> > >         Title           : Pre-Congestion Notification Encoding
>> > Comparison
>> > >         Author(s)       : K. Chan, G. Karagiannis
>> > >         Filename        :
>> draft-chan-pcn-encoding-comparison-00.txt
>> > >         Pages           : 36
>> > >         Date            : 2007-7-5
>> > >
>> > >    DiffServ mechanisms have been developed to support Quality of
>> Service
>> > >    (QoS).  However, the level of assurance that can be
>> provided with
>> > >    DiffServ without substantial over-provisioning is
>> limited.  Pre-
>> > >    Congestion Notification (PCN) investigates the use of per-flow
>> > >    admission control to provide the required service
>> guarantees for
>> the
>> > >    admitted traffic.  While admission control will protect the QoS
>> under
>> > >    normal operating conditions, an additional flow termination
>> > > mechanism   is necessary in the times of heavy congestion (e.g.
>> caused
>> > by route
>> > >    changes due to link or node failure).
>> > >
>> > >    Encoding and their transport are required to carry the
>> congestion
>> and
>> > >    pre-congestion information from the congestion and
>> pre-congestion
>> > >    points to the decision points.  This document provides a survey
>> of
>> > >    several encoding methods, using comparisons amongst
>> them as a way
>> to
>> > >    explain their strengths and weaknesses.
>> > >
>> > >
>> > >
>> > >A URL for this Internet-Draft is:
>> >
>> >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-c
>> omparison-
>> > 00.txt
>> > >
>> > >To remove yourself from the I-D Announcement list, send a
>> message to
>> > >[email-masked] with the word unsubscribe in the body
>> of
>> > >the message.
>> > >You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>> > >to change your subscription settings.
>> > >
>> > >Internet-Drafts are also available by anonymous FTP. Login
>> with the
>> > >username "anonymous" and a password of your e-mail address. After
>> > >logging in, type "cd internet-drafts" and then "get
>> > >draft-chan-pcn-encoding-comparison-00.txt".
>> > >
>> > >A list of Internet-Drafts directories can be found in
>> > >http://www.ietf.org/shadow.html or
>> > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> > >
>> > >Internet-Drafts can also be obtained by e-mail.
>> > >
>> > >Send a message to:
>> > >         [email-masked].
>> > >In the body type:
>> > >         "FILE /internet-drafts/draft-chan-pcn-encoding-comparison-
>> > 00.txt".
>> > >
>> > >NOTE:   The mail server at ietf.org can return the document in
>> > >         MIME-encoded form by using the "mpack" utility.
>> To use this
>> > >         feature, insert the command "ENCODING mime" before the
>> "FILE"
>> > >         command.  To decode the response(s), you will
>> need "munpack"
>> or
>> > >         a MIME-compliant mail reader.  Different
>> MIME-compliant mail
>> > readers
>> > >         exhibit different behavior, especially when dealing with
>> > >         "multipart" MIME messages (i.e. documents which have been
>> split
>> > >         up into multiple messages), so check your local
>> documentation on
>> > >         how to manipulate these messages.
>> > >
>> > >Below is the data which will enable a MIME compliant mail reader
>> > >implementation to automatically retrieve the ASCII version of the
>> > >Internet-Draft.
>> > >
>> > >Content-Type: text/plain
>> > >Content-ID: <[email-masked]>
>> > >
>> > >ENCODING mime
>> > >FILE /internet-drafts/draft-chan-pcn-encoding-comparison-00.txt
>> > >
>> > >
>> >
>> ><ftp://ftp.ietf.org/internet-drafts/draft-chan-pcn-encoding-c
>> omparison-
>> > 00.txt>
>> > >_______________________________________________
>> > >I-D-Announce mailing list
>> > >[email-masked]
>> > >https://www1.ietf.org/mailman/listinfo/i-d-announce
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > PCN mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/pcn
>>
>>
>> _______________________________________________
>> PCN mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pcn
>>
>

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 23 Jul 2007 17:07:18 +0100

Georgios,

I've had a chance to read this one now - detailed review embedded...

>Georgios: Thank you very much!

I agree.

>I would like to keep this section.

I disagree. Like Phil, I think it would be useful to try to cut down 
drastically. The set of choices need to be laid out clearly, but I found 
there was much more text than was needed for clarity. Once/if this becomes 
an RFC, no-one is going to read it as the first or only thing they ever 
read about PCN. So you can refer to things like the architecture and get 
straight to the point in this one.

- I agree with Phil that the marking algo text is fairly redundant
- there also seem to be a lot of options that could just be killed off at 
birth (see later for specifics) because they don't work sufficiently to go 
forward. They just lead to a combinatorial explosion of text later, and 
waste IETF cycles discussing them.

To cut down the choices, you need a criterion for a scheme getting 
mentioned in this draft. I suggest it should be that someone has already 
proposed it as part of a coherent PCN system, or that you (the authors) can 
propose an encoding that would be a better alternative to one already 
coherently proposed.

So Fig 1 should have a ref column giving the ref that describes the option. 
Then you make a rule: No ref, no row.

> >> the table is very useful.

I agree - very useful format.

Another suggestion: Could a lot of the following text also be tabulated and 
the longhand text removed.

>that are supported by each option.

Please reconsider your response. Phil's talking sense.

The top level question is how many states do we want to encode. Then, the 
second level question is how do we encode them.

>Georgios: I do not understand this remarks. Maybe we can discuss them in

I'm trying to unpick how Georgios (and Kwok) are thinking. I understand 
Phil's comments perfectly, so there must be some misunderstanding here.

> >> Should there be an option similar to option 9, but with PCN dscp?

In fact, I don't understand why any of 5-9 are in the table at all as they 
don't distinguish PCN from non-PCN (see my response "Yes, of course" to 
Kwok's original question asking whether this was a key requirement).

Here's quotes from options 5-9:
===========================================================================
5: "The use of Not-ECT will separate PCN traffic from non[e] PCN traffic 
with the big exception of [for] ECN traffic."

6: "Encoding Option 6 suffers the same issue as Encoding Option 5 on 
ability to separate traffic and indications between PCN and ECN traffic."

7: "But this still suffers the same problems as Encoding Options 5 & 6"

8: "But then it cannot distinguish PCN/ECN capable traffic from non[e] 
PCN/ECN capable traffic, and still suffers the same issues as Encoding 
Options 5, 6 and 7."

9: "But it still suffers the lack of ability to be distinguished from 
RFC3168 ECN traffic."
===========================================================================

So, all of options 5-9 should be killed. No-one has proposed them anyway 
and they don't work.

However, two of the ECN field combinations in them (6 & 9) should be 
"reincarnated": two new ECN+DS combinations should be created exactly like 
6 & 9 except with 'PCN' in the DSCP column.

>Georgios: I do not understand this remarks. Maybe we can discuss them in

I believe Phil was trying to say what I've tabulated below - does this 
help? The numbers in the body are for the different DSCPs needed (ie 0 = 
DSCP0, 1 = DSCP1, 2 = DSCP2 etc).

Encodg Option  10       11      12      13
Not congested   0       0       0       0
Admisn marked   1       -       1       1
Termin marked   2       1       1       1
ECMP affected   3       2       -       2

12 is Anna's single marking scheme using just DSCPs rather than DSCP + ECN

13 is as 12, but using another DSCP for ECMP affected.

AM & TM only need one DSCP, because Anna's single marking proposal requires 
one less state (because the egress calculates both admission and 
termination information from one marking state).

>Georgios: will clarify!

I think this is a (unsuccesful?) attempt to invent an ECN-only scheme that 
makes sense (as I've said, I don't think any ECN-only scheme will ever make 
sense).

S.3.1.2 (Option 2) Why is additional control and separation of AM & TM to 
provide edge nodes with added capabilites out of scope? Sounds like it 
should be very much in scope to me, but I don't know what is referred to here.

>Georgios: yes this is taken from Briscoe-cl-phb draft.

It was one of Joe's ideas documented in the cl-phb draft

>and transport a different channel than the data path.

I'd rather the arch doc explained why out-of-band signalling needs more 
complexity to authenticate it than in-band and so out of scope of PCN, then 
we could just delete it from this doc.

That doesn't mean we're stopping people doing OOB signalling or saying they 
shouldn't, it's just not relevant to PCN if they do.

> >> and later handle the more detailed aspects.

I strongly urge the authors to follow Phil's advice here.

> >> earlier Briscoe-cl-architecture drafts - could adapt text from there]

draft-ietf-tsvwg-ecn-mpls is going to WG last call. Pls read it - it has a 
lot about how PCN marking might be encoded into MPLS (without pre-judging 
this PCN w-g encoding debate).

> >> - based on your text in S2]

I agree with Phil. There's been little/no debate on whether dealing with 
ECMP is best done by
a) encoding in packet markings or
b) by finding some way to include a path identifier in packets.

I can give lots of reasons why ECMP affected marking might not work well.

[Here's one... Imagine a scenario with a crowd converging on an egress 
boundary node over different ECMP paths. Links on more than 1 (e.g. 2) of 
the paths might start AM, with one marking at a much lower level than the 
other. Both paths would start affected marking. But affected marking only 
helps if just one path is affected, or of all affected paths have the same 
marking level.

Termination marking would suffer exactly the same problem.]

An alternative solution might be to find a way for the egress to 
distinguish measurements from each separate ECMP path, by unpicking the 
path identifiers that ECMP is using to separate the paths in the first place.

This isn't the place to discuss the merits of solutions to ECMP (not this 
draft, and not this mail thread). So I suggest for now this draft just 
documents the possible need for an ECMP codepoint, and in the comparison 
notes those encodings that would or would not have space for it.

>Georgios: Check and discuss the above issues in Chicago

I agree this should be considered - Anna's single marking is the ref here 
(I'm not saying I agree, just that it should be considered).

> >> 4.1.5. explain what 'alternate ECN semantics' means

I disagree with Phil here. See my comment earlier about keeping this I-D 
short by referring out. I'd rather you (Georgios & Kwok) didn't repeat 
RFC4774 here in the interests of brevity.

In S4.2.4 on distinguishing PCN from non-PCN, I agree with your second 
option in the last para of the section: ie. don't have a special DSCP for 
Not-PCN-Capable, because this role is fulfilled by all the DSCPs that 
aren't PCN DSCPs.

> >> S4.2.5 I didn't follow what cases you were distinguishing.

I don't agree with (or don't understand) this statement in the draft: 
"There are two issues indicated here. First: the ability to distinguish PCN 
traffic from non[e] PCN traffic. Second: the ability to distinguish PCN 
from ECN traffic."

I think a lot of these misunderstandings would be solved if you defined 
what you think you mean (in terms of scheduling behaviour as well as 
marking behaviour) by
- PCN traffic
- non-PCN traffic
- ECN traffic

See point below about Fred Baker's EF-ADMIT draft and the list discussion 
started by Kwok on this.

> >> ECN nonce,

The ECN nonce only works if the receiver processes the packets in order. In 
this case, that would mean the PCN-ingress-node would have to add sequence 
numbers to all the packets in the aggregate and the PCN-egress-node would 
have to bring the aggregate of packets back into order to check the none sum.

Even then, the ECN nonce only provides protection once every feedback 
message. That was useful with frequencies of feedback much higher than 
marking frequencies (like the feedback every other packet you get with 
TCP). PCN envisages feedback on signalling timescales (at minimum every few 
thousand packets).

So even if there was reliable ordering, a binary nonce would only allow the 
PCN-ingress-node to detect a change to the last packet marking before each 
feedback signal. And, of course, it doesn't allow the network to check if 
the PCN-ingress-node is cheating.

See draft-briscoe-re-pcn-border-cheat-00.txt for my suggested encoding to 
deal with a wide range of anti-cheating cases. But other encodings are 
possible - I'm not religious about this. I will write-up the constraints I 
believe we have on the encoding.

In a single trust domain scenario, we don't need anti-cheating codepoints. 
Anti-cheating falls into the category of things to consider for when we 
move to a multi-domain scenario. Having done that exercise I can assure you 
that a codepoint for the ECN nonce is not needed in PCN scenarios.

>eg in an 'unusual situation' such as the PCN pkt

The appendix of cl-phb on all the coding choices known at that time 
contains excellent (and brief) text you can use for this draft. It already 
included most of the workable choices you've covered, except it just needed 
discussion of the extra codepoint that might be needed for ECMP Affected 
(and one or two new ideas added from the list since, such as Anna's single 
marking). Of course, it included the RMD/LC Diffserv only encoding.

In writing CL-PHB, a lot of time was spent taking combinations that were 
effectively equivalent but just with arbitrarily different choices of 
codepoints, and working out which ones were more robust to config errors 
(alt ECN semantics discussion) or the presence of unexpected legacy routers 
(S.4.1.6 of your I-D) etc. All that work was documented succinctly, and 
could be easily copied and pasted into this draft.

A large amount of all the authors' time (including yours) had been spent 
narrowing down the coding choices to those that represented the different 
trade-offs each person thought important, so that the list could discuss this.

>Georgios: We will discuss this in CHicago

Yes, the WG chairs have already said we should take multidomain into 
account when considering encodings, but they need to re-affirm how deeply 
that means we need to go.

In section 6, I suggest all the paras except the last should be moved to an 
architecture doc - they aren't security issues about the encoding, but just 
general architectural security issues. The last para needs expanding to 
address the above issues.

Concerning the first para (MLPP), there is an impact on encoding but its 
orthogonal to PCN encoding and dealt with already in MLPP documents.

Other constraints should be mentioned:

1. Architectural intent of different fields (DS & ECN)
------------------------------------------------------
There was a long discussion on the tsvwg mailing list way back about this 
(between you & I) that could be summarised in your I-D.

2. PCN encoding encapsulation and decapsulation:
-----------------------------------------------
Within a PCN domain there may be arbitrary encapsulations of the outer IP 
header in further outer headers, either as packets cross link layers that 
support PCN (e.g. see draft-ietf-ecn-mpls-01.txt) or because of IP in IP 
tunnelling (e.g. between two sites of an enterprise that want IPsec between 
them as well as PCN reservations). We cannot and should not constrain all 
tunnelling to be outside a PCN domain.

An ideal PCN encoding would allow any tunnel or link encapsulation 
implementation to just encapsulate packets with the same rules for 
processing the ECN and DS fields as non-PCN packets. Otherwise, all tunnel 
and link technology vendors have to know about PCN as an exception.

See "Layered Encapsulation of Congestion Notification" 
<draft-briscoe-tsvwg-ecn-tunnel-00.txt> (I posted a note about this to the 
PCN list in Jun 07).

This relates to the point about architectural intent of the fields: tunnels 
will treat the fields differently depending on their architectural intent. 
The DS field is processed differently by tunnels than the ECN field, 
because the ECN field has a special codepoint (Not-ECT) and a ranking of 
codepoints (CE>ECT) that makes some transitions illegal. PCN is similar. It 
can have a multi-level ranking (CE>TM>AM) and a Not-PCN state (excuse my 
abbreviated terminology). Tunnels treat DS differently, just copying it.

3. Distinguishing admission controlled from non-admission controlled
--------------------------------------------------------------------
The draft should refer to (and take accont of) Fred Baker's "DSCPs for 
Capacity Admitted Traffic" <draft-ietf-tsvwg-admitted-realtime-dscp-01> 
with its suggestions on how to distinguish between admission controlled EF 
and non-admission controlled. It should also take account of the discussion 
on this subject started by Kwok recently.

Nits
----
Section 1: ECN in RFC3168 was not only designed for TCP. It was designed 
into IP for all transports but the TCP-ECN spec was defined in the same 
doc, at the request of the Transport ADs at the time.

Section 2:
3 occurrences of wording that (confusingly) implies PCN is already deployed.
"PCN based mechanisms are used..."
"the current available PCN based algorithms"
"the current PCN detection"

S.2.1: Your draft implies CL-PHB is one proposal, whereas it was a 
comparison of 5 different proposals. As editor, I know Phil was very 
careful not to recommend one above the others (the one used in the body of 
the text was "just to be concrete"). So there's no such thing as "in CL-PHB 
a solution has been developed" or "the main encoding scheme used in CL-PHB".

Figure 1 -> Table 1

S.3 Surely there's no difference between Not-CE (Option 8) and ECT (Option 9)?

Hope this all helps.

Bob

> >> ><ftp://ftp.ietf.org/internet-drafts/draft-chan-pcn-encoding-c>> 
> omparison-
> >> > 00.txt>

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: <[email-masked]>
Date: Mon, 23 Jul 2007 17:00:50 +0100

in-line
thanks
phil

________________________________

From: Georgios Karagiannis [mailto:[email-masked]]
Sent: Sat 21/07/2007 07:17
To: [email-masked]; Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] Fwd: I-D ACTION:draft-chan-pcn-encoding-comparison-00.txt

[phil] well it's supposed to be a survey of encoding, not a survey of algorithms. i think the section degrades from the draft.

[phil] sorry, what is an 'encoding feature'? why are "not congested" and "termination control" both 'encoding features'. i must admit i'm still confused. although your final sentence is true, this is most relevant for drafts about teh reaction of PCN-boundary-nodes - it doesnt really have much to do with encoding choices.

[phil] the functionality that can be supported by the end systems and the encoding choice are fairly independent things. on reflection, i think my original comment here is the most critical one. it seems the most fundamental decision for this draft is how many PCN codepoints are needed.

[phil] sure. 

Georgios: will clarify!

[phil] ok. just to point out then that you have misunderstood it in your draft.

[phil] thinking more about this, i think probably the Architecture draft should discuss this. personally i think the arch doc should make more choices than it does at the moment - so we should state (explain) in that doc that PCn will only look at data pkt marking mechanisms, and not at explicit signalling of congestion (from a pre-congested node to the egress]

[phil] also the drfqat-briscoe-cl-phb has an appendix that compares 4 or 5 different encoding options, including issues related to what's now rfc4774. think we need to re-visit that and expand/change as needed?

[phil] yes (well it's not me proposing it - what was agreed in BoF)

Best regards,
Georgios

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 23 Jul 2007 13:19:14 -0400

My personal opinion on the direction of the draft is:

1. Simplify the draft by focusing on Encoding and not Algorithm.
     I actually have the same opinion and are trying to de-emphasize 
the Algorithm parts
     of the draft by moving them to the appendix.  I have also 
removed the more detailed
     descriptions of 3sm algorithm from the appendix (the one that I 
can remove without
     making someone feel bad that their algorithm is not represented 
in this draft).
     (I wanted people to read the short 3sm draft instead of the summary. :)

2. I wanted to make the Encoding comparison (and choices) be as independent as
     possible from the Algorithm comparison (and choices).  We have 
wrote the latest
     Algorithm drafts without calling for specific Encoding (the 
bits), just indicating
     the "states" the Algorithm requires/uses to carry the 
information output of the
     Algorithms.  Hence we should try to continue to achieve the "independence"
     goal of the draft.

3. There may be cases where special considerations are applicable wrt possible
     additional "states/modes".  For example, do we need an "ECMP 
Handling State/Mode"?
     We may want to add that as a "state/mode" (lets just use the 
word "state"), this should
     be one of the open issues.
     Or we may want to do this as an exception (the special 
consideration), and not as the rule.
     This is just 2 possible way to move this forward.

4.  The -00 version have the net relatively wide open.  We will want 
to start narrowing down
      the net relatively quickly with -01.  Hence the table in Figure 
1 will be shorten quickly.

Thanks!
-- Kwok --

At 12:07 PM 7/23/2007, Bob Briscoe wrote:
>drastically. The set of choices need to be laid out clearly, but I 
>found there was much more text than was needed for clarity. Once/if 
>this becomes an RFC, no-one is going to read it as the first or only 
>thing they ever read about PCN. So you can refer to things like the 
>architecture and get straight to the point in this one.
>
>- there also seem to be a lot of options that could just be killed 
>off at birth (see later for specifics) because they don't work 
>sufficiently to go forward. They just lead to a combinatorial 
>explosion of text later, and waste IETF cycles discussing them.
>
>mentioned in this draft. I suggest it should be that someone has 
>already proposed it as part of a coherent PCN system, or that you 
>(the authors) can propose an encoding that would be a better 
>alternative to one already coherently proposed.
>
>So Fig 1 should have a ref column giving the ref that describes the 
>option. Then you make a rule: No ref, no row.
>
>
>> >>
>Another suggestion: Could a lot of the following text also be 
>tabulated and the longhand text removed.
>
>> >>
>The top level question is how many states do we want to encode. 
>Then, the second level question is how do we encode them.
>
>I'm trying to unpick how Georgios (and Kwok) are thinking. I 
>understand Phil's comments perfectly, so there must be some 
>misunderstanding here.
>
>In fact, I don't understand why any of 5-9 are in the table at all 
>as they don't distinguish PCN from non-PCN (see my response "Yes, of 
>course" to Kwok's original question asking whether this was a key requirement).
>
>5: "The use of Not-ECT will separate PCN traffic from non[e] PCN 
>traffic with the big exception of [for] ECN traffic."
>
>8: "But then it cannot distinguish PCN/ECN capable traffic from 
>non[e] PCN/ECN capable traffic, and still suffers the same issues as 
>Encoding Options 5, 6 and 7."
>
>9: "But it still suffers the lack of ability to be distinguished 
>from RFC3168 ECN traffic."
>So, all of options 5-9 should be killed. No-one has proposed them 
>anyway and they don't work.
>
>"reincarnated": two new ECN+DS combinations should be created 
>exactly like 6 & 9 except with 'PCN' in the DSCP column.
>
>I believe Phil was trying to say what I've tabulated below - does 
>this help? The numbers in the body are for the different DSCPs 
>needed (ie 0 = DSCP0, 1 = DSCP1, 2 = DSCP2 etc).
>
>AM & TM only need one DSCP, because Anna's single marking proposal 
>requires one less state (because the egress calculates both 
>admission and termination information from one marking state).
>
>
>> >>
>> >> Don't understand NDS-CE
>>Georgios: will clarify!
>
>I think this is a (unsuccesful?) attempt to invent an ECN-only 
>scheme that makes sense (as I've said, I don't think any ECN-only 
>scheme will ever make sense).
>
>S.3.1.2 (Option 2) Why is additional control and separation of AM & 
>TM to provide edge nodes with added capabilites out of scope? Sounds 
>like it should be very much in scope to me, but I don't know what is 
>referred to here.
>
>> >>
>I'd rather the arch doc explained why out-of-band signalling needs 
>more complexity to authenticate it than in-band and so out of scope 
>of PCN, then we could just delete it from this doc.
>
>That doesn't mean we're stopping people doing OOB signalling or 
>saying they shouldn't, it's just not relevant to PCN if they do.
>
>
>> >>
>> >>
>> >> 4. comparison
>draft-ietf-tsvwg-ecn-mpls is going to WG last call. Pls read it - it 
>has a lot about how PCN marking might be encoded into MPLS (without 
>pre-judging this PCN w-g encoding debate).
>
>I agree with Phil. There's been little/no debate on whether dealing 
>with ECMP is best done by
>[Here's one... Imagine a scenario with a crowd converging on an 
>egress boundary node over different ECMP paths. Links on more than 1 
>(e.g. 2) of the paths might start AM, with one marking at a much 
>lower level than the other. Both paths would start affected marking. 
>But affected marking only helps if just one path is affected, or of 
>all affected paths have the same marking level.
>
>distinguish measurements from each separate ECMP path, by unpicking 
>the path identifiers that ECMP is using to separate the paths in the 
>first place.
>
>This isn't the place to discuss the merits of solutions to ECMP (not 
>this draft, and not this mail thread). So I suggest for now this 
>draft just documents the possible need for an ECMP codepoint, and in 
>the comparison notes those encodings that would or would not have space for it.
>
>I agree this should be considered - Anna's single marking is the ref 
>here (I'm not saying I agree, just that it should be considered).
>
>> >>
>I disagree with Phil here. See my comment earlier about keeping this 
>I-D short by referring out. I'd rather you (Georgios & Kwok) didn't 
>repeat RFC4774 here in the interests of brevity.
>
>In S4.2.4 on distinguishing PCN from non-PCN, I agree with your 
>second option in the last para of the section: ie. don't have a 
>special DSCP for Not-PCN-Capable, because this role is fulfilled by 
>all the DSCPs that aren't PCN DSCPs.
>
>I don't agree with (or don't understand) this statement in the 
>draft: "There are two issues indicated here. First: the ability to 
>distinguish PCN traffic from non[e] PCN traffic. Second: the ability 
>to distinguish PCN from ECN traffic."
>
>I think a lot of these misunderstandings would be solved if you 
>defined what you think you mean (in terms of scheduling behaviour as 
>well as marking behaviour) by
>- PCN traffic
>- non-PCN traffic
>- ECN traffic
>
>See point below about Fred Baker's EF-ADMIT draft and the list 
>discussion started by Kwok on this.
>
>The ECN nonce only works if the receiver processes the packets in 
>order. In this case, that would mean the PCN-ingress-node would have 
>to add sequence numbers to all the packets in the aggregate and the 
>PCN-egress-node would have to bring the aggregate of packets back 
>into order to check the none sum.
>
>Even then, the ECN nonce only provides protection once every 
>feedback message. That was useful with frequencies of feedback much 
>higher than marking frequencies (like the feedback every other 
>packet you get with TCP). PCN envisages feedback on signalling 
>timescales (at minimum every few thousand packets).
>
>So even if there was reliable ordering, a binary nonce would only 
>allow the PCN-ingress-node to detect a change to the last packet 
>marking before each feedback signal. And, of course, it doesn't 
>allow the network to check if the PCN-ingress-node is cheating.
>
>See draft-briscoe-re-pcn-border-cheat-00.txt for my suggested 
>encoding to deal with a wide range of anti-cheating cases. But other 
>encodings are possible - I'm not religious about this. I will 
>write-up the constraints I believe we have on the encoding.
>
>In a single trust domain scenario, we don't need anti-cheating 
>codepoints. Anti-cheating falls into the category of things to 
>consider for when we move to a multi-domain scenario. Having done 
>that exercise I can assure you that a codepoint for the ECN nonce is 
>not needed in PCN scenarios.
>
>
>contains excellent (and brief) text you can use for this draft. It 
>already included most of the workable choices you've covered, except 
>it just needed discussion of the extra codepoint that might be 
>needed for ECMP Affected (and one or two new ideas added from the 
>list since, such as Anna's single marking). Of course, it included 
>the RMD/LC Diffserv only encoding.
>
>In writing CL-PHB, a lot of time was spent taking combinations that 
>were effectively equivalent but just with arbitrarily different 
>choices of codepoints, and working out which ones were more robust 
>to config errors (alt ECN semantics discussion) or the presence of 
>unexpected legacy routers (S.4.1.6 of your I-D) etc. All that work 
>was documented succinctly, and could be easily copied and pasted 
>into this draft.
>
>A large amount of all the authors' time (including yours) had been 
>spent narrowing down the coding choices to those that represented 
>the different trade-offs each person thought important, so that the 
>list could discuss this.
>
>> >>
>account when considering encodings, but they need to re-affirm how 
>deeply that means we need to go.
>
>In section 6, I suggest all the paras except the last should be 
>moved to an architecture doc - they aren't security issues about the 
>encoding, but just general architectural security issues. The last 
>para needs expanding to address the above issues.
>
>Concerning the first para (MLPP), there is an impact on encoding but 
>its orthogonal to PCN encoding and dealt with already in MLPP documents.
>
>There was a long discussion on the tsvwg mailing list way back about 
>this (between you & I) that could be summarised in your I-D.
>
>Within a PCN domain there may be arbitrary encapsulations of the 
>outer IP header in further outer headers, either as packets cross 
>link layers that support PCN (e.g. see draft-ietf-ecn-mpls-01.txt) 
>or because of IP in IP tunnelling (e.g. between two sites of an 
>enterprise that want IPsec between them as well as PCN 
>reservations). We cannot and should not constrain all tunnelling to 
>be outside a PCN domain.
>
>processing the ECN and DS fields as non-PCN packets. Otherwise, all 
>tunnel and link technology vendors have to know about PCN as an exception.
>
><draft-briscoe-tsvwg-ecn-tunnel-00.txt> (I posted a note about this 
>to the PCN list in Jun 07).
>
>This relates to the point about architectural intent of the fields: 
>tunnels will treat the fields differently depending on their 
>architectural intent. The DS field is processed differently by 
>tunnels than the ECN field, because the ECN field has a special 
>codepoint (Not-ECT) and a ranking of codepoints (CE>ECT) that makes 
>some transitions illegal. PCN is similar. It can have a multi-level 
>ranking (CE>TM>AM) and a Not-PCN state (excuse my abbreviated 
>terminology). Tunnels treat DS differently, just copying it.
>
>The draft should refer to (and take accont of) Fred Baker's "DSCPs 
>for Capacity Admitted Traffic" 
><draft-ietf-tsvwg-admitted-realtime-dscp-01> with its suggestions on 
>how to distinguish between admission controlled EF and non-admission 
>controlled. It should also take account of the discussion on this 
>subject started by Kwok recently.
>
>Nits
>----
>Section 1: ECN in RFC3168 was not only designed for TCP. It was 
>designed into IP for all transports but the TCP-ECN spec was defined 
>in the same doc, at the request of the Transport ADs at the time.
>
>Section 2:
>careful not to recommend one above the others (the one used in the 
>body of the text was "just to be concrete"). So there's no such 
>thing as "in CL-PHB a solution has been developed" or "the main 
>encoding scheme used in CL-PHB".
>
>Figure 1 -> Table 1
>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 23 Jul 2007 20:19:39 -0400

Kwok wrote July 23, 2007
>consideration), and not as the rule.

Do it as a special case for the marking approach that needs it.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Chan, Kwok-Ho (BL60:470) 
Sent: July 23, 2007 1:19 PM
To: Bob Briscoe
Cc: [email-masked]
Subject: RE: [PCN] Fwd: I-D

     (I wanted people to read the short 3sm draft instead of the
summary. :)

2. I wanted to make the Encoding comparison (and choices) be as
independent as
     possible from the Algorithm comparison (and choices).  We have 
wrote the latest
     Algorithm drafts without calling for specific Encoding (the 
bits), just indicating
     the "states" the Algorithm requires/uses to carry the 
information output of the
     Algorithms.  Hence we should try to continue to achieve the
"independence"
     goal of the draft.

3. There may be cases where special considerations are applicable wrt
possible

Thanks!
-- Kwok --

At 12:07 PM 7/23/2007, Bob Briscoe wrote:
>> >> > >         "FILE
/internet-drafts/draft-chan-pcn-encoding-comparison-