Subject: [PCN] Usage of '01' and '10' code points

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 12 Mar 2008 12:06:12 -0400

Hi:
A discussion on PCN's use of '01' and '10' code points in the ECN field.
Much if not all of this info is in
http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-03.txt
more specifically in sections 2.2.3, 2.2.6, 3.1.4, paragraphs with 
'01' and '10' headings.

We originally proposed to use both '01' and '10' code points to 
represent one encoding
state of "Not-Pre-Congested" (or "Un-Marked") (see section 2.1 of 
encoding-comparison-03)
because:
1. For the encoding options we do this, there were enough code points 
for us to do so.
2. Doing this increase ECN Nonce friendliness for the "leakage" situations.
     Packets entering the PCN domain with '01' or '10' encoding can 
only be changed to '11'.
     If by chance the "leaked-in" '01' and '10' encoded packets 
"leaks-out" with no pre-congestion
     on its path in the PCN domain, these packets are not affected by 
the PCN domain.
     This "leaked-in" and "leaks-out" may be due to the same 
configuration error at the ingress
     and egress node.
3. Possible ratios of Admission-Marked and Termination-Marked packets 
when '11' code point
     is used for both.

But with the squeeze on the available code points due to the 
tunnelling constraints,
we should re-visit if we should use both '01' and '10' code points 
for just one encoding state.

How about:
1. Use '01' code point for Admission-Marked encoding state.
     Use '10' code point for Not-Pre-Congested (Un-Marked) encoding state.
     Please notice the use of '10' for Not-Pre-Congested to be 
friendlier to ECN not using nonce
     ('10' = ECT(0) means not congested for 3168 ECN when nonce is not used).

The trade-offs of the new encoding scheme when comparing to using 
'01' and '10' for one encoding
state are:
1.  Less ECN Nonce friendly but still ECN friendly.
2. Can not have the flexibility of the possible separation of 
Admission and Termination Marked.

The notion of "less ECN nonce friendly" can be philosophical:
- Is it better to detect a configuration error as soon as possible and fix it?
Or
- Is it better to minimize the affect of the configuration error and 
hence harder to detect
   and have it not fixed for a longer period of time?
And
- Is it OK to not be able to detect the configuration error if it 
have no functional affect?

So the trade-off of "Less ECN Nonce friendly" may be viewed as faster ECN Nonce
violation detection.

In light of the latest new constraints and trade-offs, I would like 
to ask the Working Group
to think about and comment on:
1. Should we continue to use both '01' and '10' code points for just 
ONE encoding state?
2. Will it be acceptable to use '01' and '10' code points for TWO 
encoding states?

There may be additional trade-offs not indicated above.  Please share 
them with us if you
know of additional ones.

Thank you!
-- Kwok Ho Chan --

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 12 Mar 2008 22:00:02 +0100

Hi

Given that we discuss realtime appliations that run on RTP/UDP.. 
My thoughs regarding the 01 and 10 codepoinst are that they are actually
not needed for ECN-nonce like it is done in eg RFC3540. The reason to
this is that application that run over RTP/UDP do not have anything that
resembles the nonce-sum that is available in the TCP header. It is
possible that one may implement this as a special RTCP report but as e.g
VoIP application do not have the typical client-server behavior that
exist for instance for webservers and browsers I see very little use for
the ECN nonce sum as you cannot build any trust on that anyway. Instead
the ECN-CE will be reacted upon using other mechanisms such as rate
change commands.

My take is then that in order for a PCN domain to be "ECN friendly" but
not "ECN nonce friendly" in a realtime perspective the following
requirements apply:
ECN '00' at PCN ingress should be '00' after PCN egress
ECN '01' at PCN ingress can and should be either '10' or '01' after PCN
egress
ECN '10' at PCN ingress can and should be either '10' or '01' after PCN
egress 
ECN '11' at PCN ingress should be '11' at PCN egress 
In doing like this an ECN capable node (could be a router or a 3GPP LTE
eNB) after PCN-egress will be able to set ECN CE upon experienced
congestion. The possible ECN nonce is broken with this but I don't see
this as a problem. 
ECN '00' should never be set to '10' or '10' but I guess this is
explained in RFC4774 (or is it RFC3168)

I don't expect everybody to agree, for instance DCCP can echo the ECN
nonce in the ack-vector. But then again I also here wonder how the trust
relationship is built. 

/Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kwok-Ho Chan
> Sent: den 12 mars 2008 12:06
> To: [email-masked]
> Subject: [PCN] Usage of '01' and '10' code points
> 
> Hi:
> more specifically in sections 2.2.3, 2.2.6, 3.1.4, paragraphs 
> with '01' and '10' headings.
> 
> We originally proposed to use both '01' and '10' code points 
> to represent one encoding state of "Not-Pre-Congested" (or 
> "Un-Marked") (see section 2.1 of
> encoding-comparison-03)
> because:
> 1. For the encoding options we do this, there were enough 
> code points for us to do so.
>      Packets entering the PCN domain with '01' or '10' 
> encoding can only be changed to '11'.
>      If by chance the "leaked-in" '01' and '10' encoded 
> packets "leaks-out" with no pre-congestion
>      on its path in the PCN domain, these packets are not 
> affected by the PCN domain.
> 3. Possible ratios of Admission-Marked and Termination-Marked 
> packets when '11' code point
>      is used for both.
> 
> tunnelling constraints, we should re-visit if we should use 
> both '01' and '10' code points for just one encoding state.
> 
> How about:
>      Please notice the use of '10' for Not-Pre-Congested to 
> be friendlier to ECN not using nonce
> The trade-offs of the new encoding scheme when comparing to 
> using '01' and '10' for one encoding state are:
> - Is it better to minimize the affect of the configuration 
> error and hence harder to detect
> - Is it OK to not be able to detect the configuration error 
> if it have no functional affect?
> 
> So the trade-off of "Less ECN Nonce friendly" may be viewed 
> as faster ECN Nonce violation detection.
> 
> 
> In light of the latest new constraints and trade-offs, I 
> would like to ask the Working Group to think about and comment on:
> 1. Should we continue to use both '01' and '10' code points 
> for just ONE encoding state?
> 2. Will it be acceptable to use '01' and '10' code points for 
> TWO encoding states?
> 
> There may be additional trade-offs not indicated above.  
> Please share them with us if you know of additional ones.
> 
> Thank you!
> -- Kwok Ho Chan --
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 12 Mar 2008 22:18:00 +0100

Hi

Sorry to see again that M$Outlook did some intelligent formatting on my
email.... 
I repeat the essential bullets for the sake of clarity, hopefully it
will stay intact now... 

+ ECN '00' at PCN ingress should be '00' after PCN egress

+ ECN '01' at PCN ingress can and should be either '10' or '01' after
PCN egress

+ ECN '10' at PCN ingress can and should be either '10' or '01' after
PCN egress

+ ECN '11' at PCN ingress should be '11' at PCN egress 

/Ingemar

> Behalf Of Ingemar Johansson S
> Sent: den 12 mars 2008 17:00
> To: Kwok-Ho Chan; [email-masked]
> Subject: Re: [PCN] Usage of '01' and '10' code points
> 
> Hi
> 
> My thoughs regarding the 01 and 10 codepoinst are that they 
> are actually not needed for ECN-nonce like it is done in eg 
> RFC3540. The reason to this is that application that run over 
> RTP/UDP do not have anything that resembles the nonce-sum 
> that is available in the TCP header. It is possible that one 
> may implement this as a special RTCP report but as e.g VoIP 
> application do not have the typical client-server behavior 
> that exist for instance for webservers and browsers I see 
> very little use for the ECN nonce sum as you cannot build any 
> trust on that anyway. Instead the ECN-CE will be reacted upon 
> using other mechanisms such as rate change commands.
> 
> My take is then that in order for a PCN domain to be "ECN 
> friendly" but not "ECN nonce friendly" in a realtime 
> perspective the following requirements apply:
> ECN '00' at PCN ingress should be '00' after PCN egress ECN 
> '01' at PCN ingress can and should be either '10' or '01' 
> after PCN egress ECN '10' at PCN ingress can and should be 
> either '10' or '01' after PCN egress ECN '11' at PCN ingress 
> should be '11' at PCN egress In doing like this an ECN 
> capable node (could be a router or a 3GPP LTE
> eNB) after PCN-egress will be able to set ECN CE upon 
> experienced congestion. The possible ECN nonce is broken with 
> this but I don't see this as a problem. 
> ECN '00' should never be set to '10' or '10' but I guess this 
> is explained in RFC4774 (or is it RFC3168)
> 
> I don't expect everybody to agree, for instance DCCP can echo 
> the ECN nonce in the ack-vector. But then again I also here 
> wonder how the trust relationship is built. 
> 
> /Ingemar
> 
> 
> 
> Behalf Of 
> > Kwok-Ho Chan
> > represent one encoding state of "Not-Pre-Congested" (or
> both '01' 
> > and '10' code points for just one encoding state.
> > 
> > How about:
> >      ('10' = ECT(0) means not congested for 3168 ECN when 
> nonce is not 
> > used).
> > 
> > - Is it better to detect a configuration error as soon as 
> possible and 
> > fix it?
> > Or
> would like to 
> > ask the Working Group to think about and comment on:

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 13 Mar 2008 16:30:51 -0400

Hi Ingemar:
I think we are in agreement.
Please see inline below.
Thanks!
-- Kwok --

>+ ECN '10' at PCN ingress can and should be either '10' or '01' after

IMHO,
The ECN '01' and '10' codepoints at ingress can also become '11' at egress.
And this is still acceptable to ECN, how friendly this is to ECN is still
an open question.
The ECN nonce friendliness may not be needed as you are pointing out.