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

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 05 Jul 2007 16:13:02 -0400

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],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked]
>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-comparison-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-comparison-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

---

From: <[email-masked]>
Date: Thu, 19 Jul 2007 11:12:25 +0100

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.

1. motivation & goals
this seems quite long for this draft, maybe the material is more
suitable elsewhere eg architecture draft?

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?

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).

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)

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.

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)

Don't understand NDS-CE

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

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.)

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.

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

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

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.

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

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
> >List-Unsubscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
> >List-Subscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>[email-masked],[email-masked],[email-masked],bharrath@nortel
.c
om,[email-masked],[email-masked],[email-masked],huiwc@nortel
.c
om,[email-masked],[email-masked],[email-masked],khchan@norte
l.
> com
> > mechanism   is necessary in the times of heavy congestion (e.g.
caused
> by route
> >You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce