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

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 22 Feb 2008 14:08:18 -0500

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
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 10:08:27 -0000

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

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

Pros:
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.

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. 

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

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

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

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)

Hope you're de-fevered!
phil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kwok-Ho Chan
> Sent: 22 February 2008 19:08
> To: [email-masked]
> Subject: [PCN] Encoding Option: '01' & '10' Encoding
> 
> Hi all:
> For ECN:  '01' = ECT(1), '10' = ECT(0).  Meaning Not Congested, and
ECN
> Capable
> It is a good suggestion if we have more bits to use.  But we don't,
and
> the use
>      If a PCN Edge Node receives the '11' encoding and if we choose it
to
> mean
>      used for TCP) friendly.  Detailed discussions of how friendly
should
> be
>      If an ECN End Node receives the '11' encoding, it will mean
interpret
> it
>      ECN (TCP) endpoints?  If the ECN endpoint handles this PCN
packet,
> then
http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-
> 02.txt

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 25 Feb 2008 11:08:18 -0500

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

>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

This is currently in:

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.

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

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

>(Kwok, your scheme is quite good from this point of view. '00' sneaking

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

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

>PCN-domain, then some complexity is needed at the PCN-boundary-nodes

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

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 18:01:19 -0000

Some follow-ups below
Thanks
phil

> From: Kwok-Ho Chan [mailto:[email-masked]]
> Sent: 25 February 2008 16:08

> agree is handled by the use of the PCN DSCP, for example: "PCN 1".

Good point, PCN-capable is not the optimum term. 

> How about the use of "NP" to denote "NOT PRE-CONGESTED" ??
Suggested Unmarked (UM), to keep it similar to AM & TM (and also I think
NP is easy to wrongly guess as Not PCN-capable - in a draft which
somewhere does have this as a codepoint, if I remember right)

> Please notice this is only a summary of the Pros, please read the

I did look at that and tried to extract the pros and cons
(S3.1.1-S3.1.3). I don't think I missed any pros. I also added 2 cons. I
think we need to narrow down to just a few choices on the table &
understand them fully. Personally I find there are too many options in
the draft (in addition to the 9 that get an Option number, there are
several other unnumbered variants mentioned)
 
S3.1.4 I just re-read - there are some detailed bits I don't follow. We
should make it crystal clear that the technique to meet 4774 concerns is
separate dscp + configuration that all PCN-routers are configured with
pcn. 

> This also allows easy use of PCN with VPNs.  

Please explain, don't understand. 

> For the example you provided (similar to draft's Option 1), this may
be
> true.

I re-read the paragraph under Fig 1 where you explain what option 2 is &
I don't understand it. 
I think it may be the idea that both 01 & 10 mean Unmarked (ie not
Pre-congested) and:
AM is indicated by setting the codepoint of a 01 pkt to 11
TM is indicated by setting the codepoint of a 10 pkt to 11
If so, this is clearly an option that needs some careful discussion of
potential Cons, as there are new types of consideration compared with
Option 1. for example:
- how do you ensure a regular supply of 01 & 10 at every PCN-router?
- is this still guaranteed to work if the 
- what are the implications on reaction time of the overall system to
pre-congestion?
Perhaps the answers are just setting alternate pkts to 01 & 10 at the
ingress node, and accepting the reaction time doubles. Perhaps something
nasty can happen.
You do no mention whether there are any pros to this approach. 

Sorry, I made a very confusing typo. Meant:
> >o  If a packet (in a PCN flow) arrives at the *ingress* with its ECN
= 01, ....

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 25 Feb 2008 13:39:29 -0500

Phil:
I will try to provide the responses for the short answers below.
For the long ones, I will try to add them into the draft.
Thanks!
-- Kwok --

>somewhere does have this as a codepoint, if I remember right)

Kwok:
OK, I will change them to "UM" for UnMarked to indicate No 
Pre-congestion detected.

>several other unnumbered variants mentioned)

Kwok:
I am trying to use the notion of similarities (with similar pros and cons)
and differences (with different pros and cons) to minimize the number
of options.  And the length of the draft.

>separate dscp + configuration that all PCN-routers are configured with

I will try to make the clarification in the draft.

>Please explain, don't understand.

Kwok:
I have a short sub section on this in the draft as a pro for using DSCP+ECN.

>You do no mention whether there are any pros to this approach.

Kwok:
OK, some clarification is in order.

> > >o  If a packet (in a PCN flow) arrives at the *ingress* with its ECN

Kwok:
Got it.
I am thinking of pushing the determination of which packet should
be allowed to use the PCN DSCP (hence the entering of the PCN domain)
as a function of the PCN Ingress Node.  Notice this will also give the
function of Inter-PCN-Domain setup, etc to the PCN Ingress Node.
With the encoding to explain the corner cases of the un-intended "leaking"
of packets into and out of the PCN domain.

---

From: Michael Menth <[email-masked]>
Date: Tue, 26 Feb 2008 10:33:32 +0100

Hi,

> OK, I will change them to "UM" for UnMarked to indicate No 
Sorry to be picky on nomenclature again! Any codepoint is a marking. 
Therefore, "unmarked" is not a good term. I strongly prefer "no 
pre-congestion" or "not pre-congested" (NP). This is more precise than 
the colloquial "unmarked" which has no relation to its semantics within 
PCN. Having good nomenclature is important for novices to easily catch 
up with the system.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 11:22:20 -0000

> I have a short sub section on this in the draft as a pro for using

Where? {I searched for vp, but this didn't find any]

> as a function of the PCN Ingress Node.  Notice this will also give the

S5.2 of the architecture draft [PCN-ingress-node functions] already says

"   o  Packet classify - decide whether an incoming packet is part of a
      previously admitted microflow, by using a filter spec (eg DSCP,
      source and destination addresses and port numbers)
"
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 26 Feb 2008 12:49:39 +0100

Hi

Trying to understand Option 2 in figure 1 in the PCN encoding comparison
draft.
As I understand it this option seems to be relatively transparent to end
to end ECN. What confuses me a bit is the idea that 
AM is indicated by setting the codepoint of a 01 pkt to 11
TM is indicated by setting the codepoint of a 10 pkt to 11

My question is how do we know that the "11" is to be interpreted as AM
or TM as we don't know if it was "01" or "10" before being remarked to
"11" in a PCN node at least in the ECT pattern is random (as the nonce
in RFC3540)?

Is the idea that the PCN ingress node will override the ECT pattern to a
deterministic "01" "10" "01" .... pattern ?

/Ingemar

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kwok-Ho Chan
> Sent: den 25 februari 2008 19:39
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] Encoding Option: '01' & '10' Encoding
> 
> Phil:
> > > This is different from "PCN-capable" encoding state, 
> which I believe
> >we
> >Suggested Unmarked (UM), to keep it similar to AM & TM (and also I 
> >think NP is easy to wrongly guess as Not PCN-capable - in a 
> draft which 
> > > >o  If a packet (in a PCN flow) arrives at the egress 
> with its ECN =
> >01,

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 13:42:17 -0000

> deterministic "01" "10" "01" .... pattern ?

it isnt overwriting as - if ect is running end to end it's tunnelled.
That basically means the pcn ingress can set these bits as it likes

so I think the idea is that (eg) ingress sets say alternate 01 & 10.
egress then measures the ratio of 01, 10 & 11 in order to deduce % AM &
TM.

phil
> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: 26 February 2008 11:50
> To: Kwok-Ho Chan; Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Subject: RE: [PCN] Encoding Option: '01' & '10' Encoding
> 
> Hi
> 
> > > > >o  For a router to classify a packet as PCN, it simply reads
its
> > >DSCP.