Re: [PCN] Encoding Option: '01' & '10' Encoding

["Kwok-Ho Chan" <[e-mail]>]

Phil and all:
Please see response inline below.
Thanks!
-- Kwok --


At 05:08 AM 2/25/2008, [e-mail] wrote:
>Kwok
>
>Just wanted to clarify what your proposal is. I think it's:
>
>PCN Meaning             ECN     DSCP
>
>Admission Mark  00      PCN 1
>PCN-capable     01      PCN 1
>PCN-capable     10      PCN 1
>Termination Mark        11      PCN 1

Kwok:
Want to clarify that the proposal I put forward with my original E-Mail
is for the '01' and '10' encoding code points.

AND '01' and '10' is to be used for "NOT PRE-CONGESTED" encoding state.
This is different from "PCN-capable" encoding state, which I believe we
agree is handled by the use of the PCN DSCP, for example: "PCN 1".

That proposal does not restrict if '00' or '11' encoding code points are
used for "Admission Marked", or "Termination Marked", or "Affected
Marked", or combinations of them.
With their choices depending on the number of encoding states needed
to be supported, etc.  Which can be a separate discussion, decision.

But I did used '11' to encode the "Termination Marked" encoding state
as an example.  And possibly used '00' to encode the "Admission Marked"
encoding state as an example.  But they are examples, they can be
swapped, combined into one encoding code point.  And should not affect
the use of '01' and '10' code point to mean NOT PRE-CONGESTED
encoding state.
Using '00' and '11' to represent "Admission Marked" and "Termination Marked"
encoding states as an example will match close to what you have indicated.
But there are much more write up for Option 1 in
http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-02.txt
with Pros and Cons and  with specific RFC 4774 discussions.

I hope people will read those sections of the draft and use them as 
Pros and Cons
and provide comments to the draft.

I am using the discussions on the list to clarify options 3 and 4 of the draft.

IMHO:
I believe the use of the term "PCN-capable" is confusing and mis-leading
when we really mean "Not Pre-Congested" or "No Pre-Congestion".
With the use of any packet using DSCP "PCN 1" means the packet is
PCN capable and should be treated using PCN treatment.

How about the use of "NP" to denote "NOT PRE-CONGESTED" ??

Notice ECN uses ECT to indicate both "ECN Capable Transport" and
"Not Congested".  Which we separated into 2 encoding states using
2 encoding code points.


>I think something like this is an option worth considering. Are these
>the pros & cons?

This is currently in:
http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-02.txt

as options 1 and 2 in Figure 1 on page 10.
As well as Toby (and your) proposal as options 3 and 4 in Figure 1 on page 10.

This write-up is to indicate the differences between the usage of the
'01' and '10' code points for options (1 and 2) and (3 and 4).



>Pros:

Kwok:
Please notice this is only a summary of the Pros, please read the 
draft for details.

>o  It only needs one DSCP, per PCN behaviour aggregate. In normal
>circumstances where the PCN-domain is configured correctly, then
>PCN-traffic is distinguished from non-PCN traffic by use of this DSCP.

Kwok:
I believe this is indicated by the current PCN charter (at least one 
interpretation of it).
I think it should be one point of discussion to clarify how the current charter
should be interpreted.


>o  For a router to classify a packet as PCN, it simply reads its DSCP.
>This is probably easier than checking both its DSCP & ECN fields.

Kwok:
This also allows easy use of PCN with VPNs.  One can even think of
a PCN domain being a PCN VPN across a provider network that the
provider can sell.  And apply strict rules on which packets can use
the PCN VPN (for example only real-time traffic that subscribed to
the PCN service).  And any other traffic just does not get to use the
PCN VPN/Domain (for example packets that are non-real-time that
can afford the delay/jitter of packet queuing and TCP and drops that
may want to use ECN).


>Unclear:
>o  If the PCN-boundary-nodes are misconfigured so that PCN packets can
>sneak out of the PCN-domain, or non PCN-packets can sneak in, then it
>needs more analysis.
>(Kwok, your scheme is quite good from this point of view. '00' sneaking
>out?)

Kwok:
This depends on what encoding state the '00' code point may be used 
for, or used at all.


>Cons
>  o  Termination marking and admission marking are not independent -
>before a router writes TM is must check that the packet isn't already
>admission marked. (Note: Over-writing a TM with AM is not allowed for
>3SM & CL, see draft-charny-pcn-comparison.)

Kwok:
Again, this depends on how '00' and '11' code points may be used.
For the example you provided (similar to draft's Option 1), this may be true.
But for draft's Option 2, this may not be true.


>o  It needs an extra DSCP, per PCN behaviour aggregate.

Kwok:
Yes, and I believe we are currently thinking of one PCN BA, for 
real-time traffic.


>o  If a packet (in a PCN flow) arrives at the egress with its ECN = 01,
>10 or 11 and it really is required to preserve this info across the
>PCN-domain, then some complexity is needed at the PCN-boundary-nodes
>(tunnelling)

Kwok:
Not totally understanding your point.
If the packets arrive without the DSCP=PCN_1, then they are not part of the
PCN domain and should not receive PCN treatments.  They can receive ECN
treatments or any other treatment types, this is out of scope for us.  I think
we just have to say they are not part of the PCN domain.

If DSCP=PCN_1, I think there are 2 cases,
1. a packet arriving at an PCN Ingress Node with DSCP=PCN_1
     and ECN='01' or '10'.
2. a packet arriving at an PCN Egress Node with DSCP=PCN_1
     and ECN='01' or '10'.
I believe we should let the DiffServ part (and possibly the VPN part) 
do its job
and explore the damage if it didn't (the safe/unsafe leakage considerations).



>Hope you're de-fevered!

My temperature dropped from 103/102 F of last week to about 100 F today.
Running hot working on the next version of the draft. :)

>phil
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Kwok-Ho Chan
> > Sent: 22 February 2008 19:08
> > To: [e-mail]
> > Subject: [PCN] Encoding Option: '01' & '10' Encoding
> >
> > Hi all:
> > Following up on Toby's E-Mail, I would like to bring out the possible
> > choices for
> > usage of '01' and '10' bit patterns (of the 2 bit ECN field in the IP
> > Header) for PCN.
> >
> > For ECN:  '01' = ECT(1), '10' = ECT(0).  Meaning Not Congested, and
>ECN
> > Capable
> > Transport, and ECN nonce usage.
> >
> > Toby's encoding suggest the NOT using of '01' and '10'.
> > It is a good suggestion if we have more bits to use.  But we don't,
>and
> > the use
> > of additional DSCPs have other affects and trade-offs.
> >
> > Alternative is to use both '01' and '10' to indicate the packet is PCN
> > capable
> > (in another words belong to a PCN capable flow).
> >
> > The benefit of using '01' and '10' is allowing it to be used for PCN
> > purpose.
> >
> > We have agreed to use a DSCP to indicate PCN Capable packets (flows),
> > hence the PCN Capable notion (encoding state) is taken care of.
> >
> > We still need to represent Not Pre-Congested notion (encoding state).
> > IMHO, the '01' and '10' bit patterns are good choices for encoding the
> > Not Pre-Congested encoding state.
> >
> > Lets visit the benefits of such use:
> > 1. Allow the representation of a PCN encoding state using ECN bits.
> >      Minimizing the use of additional DSCPs.
> >
> > 2. If a PCN '01' or '10' encoded packet receives ECN router treatment:
> >      The ECN router will not change the encoding if it does not
>experience
> >      congestion.
> >      The ECN router will change the encoding to '11' (CE) if it
> > experienced
> >      congestion, trusting the offered load to the congestion point
> > will be reduced.
> >      If a PCN Edge Node receives the '11' encoding and if we choose it
>to
> > mean
> >      Termination, then the offered load to the congestion point will
> > be reduced.
> >      PCN terminates the flow, hence this should be ECN (at least ECN
>when
> >      used for TCP) friendly.  Detailed discussions of how friendly
>should
> > be
> >      an algorithm matter and will need to involve algorithm
> > comparisons with ECN.
> >      If an ECN End Node receives the '11' encoding, it will mean
>interpret
> > it
> >      as CE and will reduce the offered load as describe by RFC 3168.
> >      How friendly is this ECN flow to the PCN domain is a discussion
> > of algorithms
> >      and will have to make assumptions of using ECN for TCP and which
> > PCN algorithm.
> >      The how friendly discussions should be part of the algorithm
> > discussions.
> >
> > 3. When ECN packets pass through PCN Interior Nodes with no Pre-
> > Congestions,
> >      no affects to ECN and PCN.  This includes ECN packets using ECN
> > nonce.
> >
> > 4. When PCN packets pass through ECN routers with no Congestions,
> >      no affects to ECN and PCN.
> >
> > 5. If we don't have to worry about ECN nonce passing through PCN
>nodes,
> >      we can use one of the two bit patterns for another PCN encoding
> > state.
> >
> > Point # 2 above discusses:
> > 1. ECN packets entering PCN domain and then leaving the PCN domain
> >      back into ECN routers and endpoints.
> > 2. PCN packets leaving the PCN domain and encounters ECN routers and
> >      PCN endpoints.  Does it make sense to talk about PCN packets
> > encountering
> >      ECN (TCP) endpoints?  If the ECN endpoint handles this PCN
>packet,
> > then
> >      it should reduce the flows offered load, the functionality PCN
> > Interior Nodes expects.
> >
> > Based on the assumption of using PCN DSCP to separate PCN traffic and
> > non PCN traffic:
> > - When we talk about ECN packet entering PCN domain, we mean somehow
> >    the ECN packet uses the PCN DSCP.  There are DiffServ methods to
> > prevent this.
> > - When we talk about PCN packet leaving PCN domain, we mean somehow
> >    the PCN packet encounters routers that does not understand the PCN
>DSCP
> >    and interpret the PCN encoding differently.
> >
> > The bad part of such use:
> > 1. Making the PCN algorithms to handle how friendly they are with ECN
> > algorithm.
> >
> > Please notice the information provided above are in:
> >
>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-
> > 02.txt
> >
> > I am adding the details of Toby's suggestions to the -03 of the draft.
> >
> > Please let us know if there are points or concerns not addressed.
> > Thanks!
> >
> > Sorry that I have been sick with the flu (fever, aches, cough, etc)
> > the past few days.
> > Just got below 100 degree temperature with my fever this morning.
> >
> > -- Kwok --
> >
> > _______________________________________________
> > PCN mailing list
> > [e-mail]
> > http://www.ietf.org/mailman/listinfo/pcn

_______________________________________________
PCN mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pcn