Subject: [PCN] FW: RE: PCN encoding option

From: <[email-masked]>
Date: Wed, 20 Feb 2008 09:56:21 -0000

All,
 
Phil and I have just been discussing the encoding draft and feel we may
have lit upon a neat solution that seems to have lots of pros and few
cons... In order to get a better feeling for this proposal I will go
through the simplified version without Affected marking first:

PCN Meaning		ECN 	 DSCP

PCN capable		00	 PCN 1
Admission Mark	11	 PCN 1
Termination Mark	11/00	 PCN 2

PCN 1 and PCN 2 are 2 different codepoints with the same PCN behaviour
aggregate.

Pros:
 o  Termination marking and admission marking are independent, eg
termination marking can be done after a packet has been admission
marked. Therefore a router can write AM or TM without having to read the
packet's PCN marking first, which is easier to implement. (Note:
Over-writing a TM with AM is not allowed for 3SM & CL, see
draft-charny-pcn-comparison.)

o  This scheme avoids giving semantics to ECT(0) and ECT(1). This is
safest option if packets leak outside the PCN region, due to some fort
of misconfiguration of the PCN-boundary-nodes (relevant for a single
domain deployment of PCN).  

o  It leaves open the possibility of using ECT(0) and ECT(1) in some
mysterious way in a future end-to-end PCN deployment

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. 

o  Incremental deployment steps are possible
[1] could deploy SM initially and later AM/TM. Just add the second DSCP.
If a router isn't upgraded at the same time nothing too horrific
happens. 
[2] could just deploy admission control & add termination later, just by
adding a new DSCP; there is no need to change the encoding and check for
backwards compatibility? Vice-versa is also ok?

Cons:
o  It needs an extra DSCP, per PCN behaviour aggregate. (Although
possibly it's OK to use the same DSCP for TM for all PCN BAs?)

o  If a packet (in a PCN flow) arrives at the egress with its ECN = 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)

o  If the PCN-domain is operating multipath routing (ECMP) that uses the
DSCP to select routes, then there may be mis-ordering of packets within
a flow. This may be OK as (1) no-one has yet said they know of an ECMP
algorithm that in practie uses the DSCP; (2) a risk of mis-ordering when
there is termination marking may be acceptable

If Affected marking is needed then the scheme can be modified as
follows:

PCN Meaning		ECN 	DSCP

PCN capable		00	PCN 1
Admission Mark	11	PCN 1
Termination Mark	11	PCN 2
Affected Mark	00	PCN 2

The pros for this scheme are broadly similar to the above. However there
is a new con which may or may not matter: If a packet is affected marked
and a later node is doing admission marking then it will reset the
affected mark to a termination mark. Work would be needed to see if this
skews the results and causes significant over-termination or not.

Please could people look through this scheme and highlight any
additional concerns that they may have (and extra benefits too). I would
like to get as many opinions as possible. 

What I want to avoid is people just emailing back with "why not try this
scheme instead". Currently we seem to have a plethora of possible
schemes on the table and people need to start putting down much clearer
pros and cons for the schemes they support... So it could be good to
have a similar "one page" email about a specific scheme that only uses
one DSCP for PCN, but uses the 01/10 codepoints instead. 

Toby 
____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Feb 2008 11:50:02 +0100

Hi Toby,

as I understand the proposal, the motivation is to avoid 01/10 
codepoints as it is not good if they leak out of the network since 01/10 
is interpreted as ECN-capable ECT(0/1) by ECN nodes. However, there is 
the same problem with 11 marking, i.e. 11-packets may not be dropped by 
ECN nodes outside the PCN domain although endpoints are not ECN capable. 
Even if 11-packets trigger flow termination, it is not guaranteed that 
exactly the marked flow going over an overloaded ECN node is terminated. 
Just want to say that this solution wants to solve a problem that exists 
only in case of misconfiguration (leaking packets), but does not fully 
achieve that objective. Therefore, I feel that spending two DSCP values 
is quite expensive.

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: Wed, 20 Feb 2008 16:44:20 -0000

Thanks Michael

I agree with you that spending one DSCP value is quite expensive (not
two, as one is spent anyway). I think the only way of really assessing
this properly is for an alternative proposal (with pros and cons) that
requires only one DSCP. Then we can see where the consensus for the best
(/least bad) encoding lies. Personally I have no axe to grind for or
against either - I'm not yet convinced that the proposal below is
definitely the way to go, until compared it in detail with other
proposals.

So I think it would be really useful to have a "1 pager" for alternative
proposal(s) before the ietf, as I think this would make Philadelphia
discussions more productive.

You're correct about one of the motivations (advantages) for this
proposal (although I don't think the issues are exactly the same for 11
leakage as 01/10 leakage).

Consider the case where 11 leaks out of the PCN domain. If the endpoints
are ECN capable, then the ECN source slows down (seems reasonable). If
they're not capable, then the impact outside the domain isn't any
different to what would happen without PCN-domain.

Consider the case where ECN-11 leaks into the PCN domain. Then this will
lead to either flow admission or termination in the PCN-domain. These
are both safe, in that the reaction is (I believe) at least as severe as
would happen in an all ECN world. 
You mention that this might not terminate the ECN-11 flow specifically
(some other flow might get terminated instead). I think this is true,
though it also implies that [1] end-to-end ECN & PCN on the same flow
really is useful, [2] the mechanism (eg tunnelling) to carry ECN-marking
transparently across the PCN-domain has also failed, [3] the flows which
are terminated aren't other ECN-11 flows that are also getting in due to
the same misconfiguration. 

Best wishes
Phil 
> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]]
> Sent: 20 February 2008 10:50
> To: Moncaster,T,Toby,CXR9 R
> Cc: [email-masked]; Eardley,PL,Philip,CXR9 R; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Briscoe,RJ,Bob,CXR9 R
> Subject: Re: FW: RE: PCN encoding option
> 
> Hi Toby,
>

---

From: <[email-masked]>
Date: Wed, 20 Feb 2008 16:48:05 -0000

Michael

> two, as one is spent anyway). 

Now remember your email where you proposed to do without any new DSCPs. 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 20 Feb 2008 17:23:59 -0000

You are correct that ECN nodes outside the PCN domain can not drop 11
marked packets (unless their buffer is full). However I think they will
simply mark the next available packet OR drop the next packet if it is
not ECN capable. Whilst this is slightly unsafe in that it may
temporarily delay the reporting of congestion and may mean a different
node is notified of the congestion, this seems a much more minor issue
than letting 10 or 01 leak. Recall that ECN implicitly builds in a
safety margin for reporting of congestion before it actually occurs.

Toby

> From: Eardley,PL,Philip,CXR9 R 
> Sent: 20 February 2008 16:44
> To: [email-masked]'; Moncaster,T,Toby,CXR9 R
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Subject: RE: FW: RE: PCN encoding option
> 
> Thanks Michael
> 
> I agree with you that spending one DSCP value is quite 
> expensive (not two, as one is spent anyway). I think the only 
> way of really assessing this properly is for an alternative 
> proposal (with pros and cons) that requires only one DSCP. 
> Then we can see where the consensus for the best (/least bad) 
> encoding lies. Personally I have no axe to grind for or 
> against either - I'm not yet convinced that the proposal 
> below is definitely the way to go, until compared it in 
> detail with other proposals.
> 
> So I think it would be really useful to have a "1 pager" for 
> alternative proposal(s) before the ietf, as I think this 
> would make Philadelphia discussions more productive.
> 
> 
> You're correct about one of the motivations (advantages) for 
> this proposal (although I don't think the issues are exactly 
> the same for 11 leakage as 01/10 leakage).
> 
> Consider the case where 11 leaks out of the PCN domain. If 
> the endpoints are ECN capable, then the ECN source slows down 
> (seems reasonable). If they're not capable, then the impact 
> outside the domain isn't any different to what would happen 
> without PCN-domain.
> 
> Consider the case where ECN-11 leaks into the PCN domain. 
> Then this will lead to either flow admission or termination 
> in the PCN-domain. These are both safe, in that the reaction 
> is (I believe) at least as severe as would happen in an all 
> ECN world. 
> You mention that this might not terminate the ECN-11 flow 
> specifically (some other flow might get terminated instead). 
> I think this is true, though it also implies that [1] 
> end-to-end ECN & PCN on the same flow really is useful, [2] 
> the mechanism (eg tunnelling) to carry ECN-marking 
> transparently across the PCN-domain has also failed, [3] the 
> flows which are terminated aren't other ECN-11 flows that are 
> also getting in due to the same misconfiguration. 
> 
> Best wishes
> Phil

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Feb 2008 18:47:09 +0100

Hi Phil,

> different to what would happen without PCN-domain.

No, there is a difference. 11-marked packets are not dropped when 
congestion occurs and if the endpoints are not ECN-capable, they don't 
backoff. That's the problem. That's why I say the solution is not fully 
sound.

Regards,

    Michael

>> codepoints as it is not good if they leak out of the network since
>>     
> 01/10
>   
>> the same problem with 11 marking, i.e. 11-packets may not be dropped
>>     
> by
>   
>> ECN nodes outside the PCN domain although endpoints are not ECN
>>     
> capable.
>   
>> exactly the marked flow going over an overloaded ECN node is
>>     
> terminated.
>   
>> Just want to say that this solution wants to solve a problem that
>>     
> exists
>   
>> achieve that objective. Therefore, I feel that spending two DSCP
>>     
> values
>   
>> is quite expensive.
>>
>> Regards,
>>
>>     Michael
>>
>>> Phil and I have just been discussing the encoding draft and feel we
>>>       
> may
>   
>>> have lit upon a neat solution that seems to have lots of pros and
>>>       
> few
>   
>>> PCN 1 and PCN 2 are 2 different codepoints with the same PCN
>>>       
> behaviour
>   
>>> aggregate.
>>>
>>> Pros:
>>> marked. Therefore a router can write AM or TM without having to read
>>>       
> the
>   
>>> safest option if packets leak outside the PCN region, due to some
>>>       
> fort
>   
>>> o  For a router to classify a packet as PCN, it simply reads its
>>>       
> DSCP.
>   
>>> [1] could deploy SM initially and later AM/TM. Just add the second
>>>       
> DSCP.
>   
>>> [2] could just deploy admission control & add termination later,
>>>       
> just by
>   
>>> adding a new DSCP; there is no need to change the encoding and check
>>>       
> for
>   
>>> o  If a packet (in a PCN flow) arrives at the egress with its ECN =
>>>       
> 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)
>   
>>> o  If the PCN-domain is operating multipath routing (ECMP) that uses
>>>       
> the
>   
>>> DSCP to select routes, then there may be mis-ordering of packets
>>>       
> within
>   
>>> a flow. This may be OK as (1) no-one has yet said they know of an
>>>       
> ECMP
>   
>>> algorithm that in practie uses the DSCP; (2) a risk of mis-ordering
>>>       
> when
>   
>>> The pros for this scheme are broadly similar to the above. However
>>>       
> there
>   
>>> is a new con which may or may not matter: If a packet is affected
>>>       
> marked
>   
>>> affected mark to a termination mark. Work would be needed to see if
>>>       
> this
>   
>>> additional concerns that they may have (and extra benefits too). I
>>>       
> would
>   
>>> What I want to avoid is people just emailing back with "why not try
>>>       
> this
>   
>>> schemes on the table and people need to start putting down much
>>>       
> clearer
>   
>>> have a similar "one page" email about a specific scheme that only
>>>       
> uses
>

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Feb 2008 18:47:23 +0100

Hi Toby,

[email-masked] wrote:
> not ECN capable. 

Well, I'm not sure about that. It would be interesting to hear from 
vendors or other people knowing how ECN marking works in details how 
this is solved.

> Whilst this is slightly unsafe in that it may

I don't know how save this marging really is since if queues build up at 
high speed, they also quickly overflow. Incipient congestion is already 
the start of congestion which is unlike PCN thresholds.

Regards,

    Michael

>>> codepoints as it is not good if they leak out of the 
>>>       
>> network since 01/10
>>     
>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. 
>>>       
>> However, there is
>>     
>>> the same problem with 11 marking, i.e. 11-packets may not 
>>>       
>> be dropped by
>>     
>>> ECN nodes outside the PCN domain although endpoints are not 
>>>       
>> ECN capable.
>>     
>>> Even if 11-packets trigger flow termination, it is not 
>>>       
>> guaranteed that
>>     
>>> exactly the marked flow going over an overloaded ECN node 
>>>       
>> is terminated.
>>     
>>> Just want to say that this solution wants to solve a 
>>>       
>> problem that exists
>>     
>>> only in case of misconfiguration (leaking packets), but 
>>>       
>> does not fully
>>     
>>> achieve that objective. Therefore, I feel that spending two 
>>>       
>> DSCP values
>>     
>>> is quite expensive.
>>>
>>> Regards,
>>>
>>>     Michael
>>>
>>>> Phil and I have just been discussing the encoding draft 
>>>>         
>> and feel we may
>>     
>>>> have lit upon a neat solution that seems to have lots of 
>>>>         
>> pros and few
>>     
>>>> cons... In order to get a better feeling for this 
>>>>         
>> proposal I will go
>>     
>>>> PCN 1 and PCN 2 are 2 different codepoints with the same 
>>>>         
>> PCN behaviour
>>     
>>>> aggregate.
>>>>
>>>> Pros:
>>>> marked. Therefore a router can write AM or TM without 
>>>>         
>> having to read the
>>     
>>>> o  This scheme avoids giving semantics to ECT(0) and 
>>>>         
>> ECT(1). This is
>>     
>>>> safest option if packets leak outside the PCN region, due 
>>>>         
>> to some fort
>>     
>>>> of misconfiguration of the PCN-boundary-nodes (relevant 
>>>>         
>> for a single
>>     
>>>> o  It leaves open the possibility of using ECT(0) and 
>>>>         
>> ECT(1) in some
>>     
>>>> o  For a router to classify a packet as PCN, it simply 
>>>>         
>> reads its DSCP.
>>     
>>>> [1] could deploy SM initially and later AM/TM. Just add 
>>>>         
>> the second DSCP.
>>     
>>>> [2] could just deploy admission control & add termination 
>>>>         
>> later, just by
>>     
>>>> adding a new DSCP; there is no need to change the 
>>>>         
>> encoding and check for
>>     
>>>> o  If a packet (in a PCN flow) arrives at the egress with 
>>>>         
>> its ECN = 11
>>     
>>>> and it really is required to preserve this info across 
>>>>         
>> the PCN-domain,
>>     
>>>> o  If the PCN-domain is operating multipath routing 
>>>>         
>> (ECMP) that uses the
>>     
>>>> DSCP to select routes, then there may be mis-ordering of 
>>>>         
>> packets within
>>     
>>>> a flow. This may be OK as (1) no-one has yet said they 
>>>>         
>> know of an ECMP
>>     
>>>> algorithm that in practie uses the DSCP; (2) a risk of 
>>>>         
>> mis-ordering when
>>     
>>>> The pros for this scheme are broadly similar to the 
>>>>         
>> above. However there
>>     
>>>> is a new con which may or may not matter: If a packet is 
>>>>         
>> affected marked
>>     
>>>> affected mark to a termination mark. Work would be needed 
>>>>         
>> to see if this
>>     
>>>> additional concerns that they may have (and extra 
>>>>         
>> benefits too). I would
>>     
>>>> What I want to avoid is people just emailing back with 
>>>>         
>> "why not try this
>>     
>>>> schemes on the table and people need to start putting 
>>>>         
>> down much clearer
>>     
>>>> pros and cons for the schemes they support... So it could 
>>>>         
>> be good to
>>     
>>>> have a similar "one page" email about a specific scheme 
>>>>         
>> that only uses
>>     
>>>> Toby Moncaster, <[email-masked]> Networks Research 
>>>>         
>> Centre, BT
>>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 21 Feb 2008 07:43:17 +0100

Hi

In this discussion it may be well worth the effort to consider the end
to end ECN usecases that we foresee when considering various PCN
encoding options. 
Please have a look at 
http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt
for a discussion of the use cases and a motivation to why end to end ECN
should be maintained even across PCN nodes even for non DF traffic.
That said I realize that there is some cost associated to the use of
DSCP codepoints, this cost must however be weighted against the risk
that other functionality like end to end ECN semantics is probably
broken if a PCN encoding option "fiddles" with the ECN bits. It is easy
to see that if one wish to maintain support for end to end ECN (not only
in DF class) it simply costs more DSCP codepoints.
I am not explicitly saying don't do this or that but I wish to avoid a
situation where one technique has to be avoided in favor of the other as
it may in the end prevent deployment of both. If one can yank the two
together so much the better even though the cost e.g in DSCP code points
is regarded as higher.

Regards
Ingemar

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: den 20 februari 2008 17:44
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PCN] FW: RE: PCN encoding option
> 
> Thanks Michael
> 
> alternative
> proposal(s) before the ietf, as I think this would make 
> Philadelphia discussions more productive.
> 
> 
> and feel we
> having to read
> > > o  Incremental deployment steps are possible [1] could deploy SM 
> > > initially and later AM/TM. Just add the second
> DSCP.
> encoding and check
> its ECN =
> (ECMP) that uses
> mis-ordering
> to see if
> "why not try
> > Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> > Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> > room B206

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 09:24:18 -0000

Ingemar

Re

> consider the end to end ECN usecases 

I believe that the emails below about Toby's encoding proposal do indeed
already consider ECN. Would appreciate it if you could add further text
to it to better capture the (pros and) cons.

> more DSCP codepoints
I think you may be proposing an encoding that uses all dscp codepoints
(as has Georgios). That's fine - but a "1 pager" setting out this option
with its pros and cons (ie similar to what toby has done below) is
needed I think! At the moment we have lots of options on the table - in
order to reach a decision, I think we really need very few options but
with their pros and cons better laid out.

I haven't managed to get to your draft yet, sorry (next week hopefully)
-
Thanks
Phil

> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: 21 February 2008 06:43
> To: Eardley,PL,Philip,CXR9 R; [email-masked];
> Moncaster,T,Toby,CXR9 R
> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R
> Subject: RE: [PCN] FW: RE: PCN encoding option
> 
> Hi
> 
affected

---

From: Michael Menth <[email-masked]>
Date: Thu, 21 Feb 2008 10:23:33 +0100

Hi Ingemar,

> should be maintained even across PCN nodes even for non DF traffic.

I understand that ECN makes sense in all the use cases you mentioned in 
your draft. I would like to know
1. How important is it to use ECN also for PCN traffic
2. Although the use cases described in the draft make perfectly sense, 
is ECN really used for these purposes in practice, in particular for 
non-TCP traffic? What's its deployment?

I see ECN as a feature to optimize TCP throughput, but it does not lead 
to a better service class. Correct me if I'm wrong!

Regards,

    Michael

>>>> and a later node is doing admission marking then it will 
>>>>         
>> reset the 
>>

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 09:38:20 -0000

> backoff. That's the problem. That's why I say the solution is not
fully
this is what I was trying to get at:

assuming the ends aren't ECN-capable:
(without PCN & with some ECN router marking 11) then the ends don't
react to 11
(with PCN marking 11 & such a pkt leaking out of the PCN-domain ) then
the ends don't react to 11

no difference?

phil

---

From: Michael Menth <[email-masked]>
Date: Thu, 21 Feb 2008 11:00:30 +0100

Hi Phil,

[email-masked] wrote:
>>> Consider the case where 11 leaks out of the PCN domain. If the
>>>       
> endpoints
>   
>>> are ECN capable, then the ECN source slows down (seems reasonable).
>>>       
> If
>   
>> backoff. That's the problem. That's why I say the solution is not
>>     
> fully
>   
>> sound.
>>
>>     
Ok, let me clarify what I mean. Yes, it's true that end nodes never 
react to 11-marked packets. The difference is: non-PCN packets have no 
reason to be remarked to 11 within a PCN domain and therefore, they 
cannot leak out of the domain with 11-marking which is different for PCN 
packets. So the problem arises only for PCN traffic but not for non-PCN 
traffic.

Regards,

    Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Feb 2008 11:06:57 +0100

Hi Phil, Hi all

In order to make a selection of one single (or two) options, I think that 
the PCN WG should get the possibility to study all the possible and PCN 
relevant encoding options.

In my opinion the goal of the encoding draft is to provide this information
to the PCN-WG.
Based on this information the PCN WG can discuss and decide which of the
options should be used.

The below text is copied from the current version of the encoding draft!
Four options are described!
Please note that the encoding draft should list all relevant options with 
advantages and disadvantages. 

Phil and Ingemar, if you can add advantages, disadvantages to the 
ones already mentioned below in Section 3.2.1 and 3.2.2 of the encoding
draft, please do.

Best regards,
Georgios

3.2.  Encoding Using DSCP Field

   In this type of encoding and transport method the congestion and
   precongestion information is encoded into the 6 DSCP bits that are
   transported in the IP header of the data packets.  Four possible
   alternatives can be distinguished, as can be seen in Figure 3, with
   details provided by draft-westberg-pcn-load-control-02.txt [4].
   Option 7 needs 2 additional DSCP values, Options 8 and 9 need three
   additional DSCP values and Option 10 needs four additional DSCP
   values.  Note that all additional and experimental DSCP values are
   representing and are associated with the same PHB.  The 1st, 2nd,
   3rd, and 4th DSCP values are representing DSCP values that are
   assigned by IANA as DSCP experimental values, see RFC 2211 [9].

 -----------------------------------------------------------------------
| DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP 4 |
|===========++==========+===========+===========+===========+===========|
| Option 6  || Not-PCN  |    PCN    |   AM/TM   |    NA     |    NA     |
|-----------++----------+-----------+-----------+-----------+-----------|
| Option 7  || Not-PCN  |    PCN    |   AM/TM   |    AfM    |    NA     |
|-----------++----------+-----------+-----------+-----------+-----------|
| Option 8  || Not-PCN  |    PCN    |     AM    |    TM     |    NA     |
|-----------++----------+-----------+-----------+-----------+-----------|
| Option 9  || Not-PCN  |    PCN    |     AM    |    TM     |    AfM    |
 -----------------------------------------------------------------------

   Notes: Not-PCN means the packet is not PCN capable.

          Figure 2: Encoding of PCN Information Using DSCP Field

3.2.1.  Benefits of Using DSCP Field

   The main benefit of using the DSCP field is that it is not affecting
   the end-to-end ECN semantics and therefore the issues and concerns
   raised in RFC 4774 [22] are not applicable for this encoding scheme.
   Another benefit is related to the fact that all 4 DSCP encoding
   options depicted in Figure 2 can support the PCN capable not
   congested (PCN) indication, the admission control (AM) and flow
   termination (TM) encoding states.  In addition Option 8 and 10 can
   support the ECMP solution.

3.2.2.  Drawbacks of Using DSCP Field

   This type of encoding needs to use per PHB, in addition to the
   original DSCP and depending on the encoding option used, one, two,
   three, or four DSCP values, respectively.  These additional DSCP
   values can be taken from the DSCP values that are not defined by
   standards action, see RFC 2211 [9].  Note that all the additional
   DSCP values are representing and are associated with one PHB.  The
   value of this DSCP/PHB can either follow a standards action or use a
   value that is applied for experimental or local use.  It is important
   to note that the number of the DSCP values used for local or
   experimental use is restricted and therefore the number of different
   PHBs supported in the PCN domain will also be restricted. 

Best regards,
Georgios

> Sent: donderdag 21 februari 2008 10:24
> To: [email-masked]; 
> [email-masked]; [email-masked]
> I believe that the emails below about Toby's encoding 
> proposal do indeed already consider ECN. Would appreciate it 
> if you could add further text to it to better capture the 
> (pros and) cons.
> 
> > more DSCP codepoints
> I think you may be proposing an encoding that uses all dscp 
> codepoints (as has Georgios). That's fine - but a "1 pager" 
> setting out this option with its pros and cons (ie similar to 
> what toby has done below) is needed I think! At the moment we 
> have lots of options on the table - in order to reach a 
> decision, I think we really need very few options but with 
> their pros and cons better laid out.
> 
> 
> > situation where one technique has to be avoided in favor of 
> the other
> as
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of [email-masked]
> > > I agree with you that spending one DSCP value is quite expensive 
> > > (not two, as one is spent anyway). I think the only way of really 
> > > assessing this properly is for an alternative proposal (with pros 
> > > and cons) that requires only one DSCP.
> > > encoding lies. Personally I have no axe to grind for or against 
> > > either - I'm not yet convinced that the proposal below is 
> definitely 
> > > the way to go, until compared it in detail with other proposals.
> > >
> > > proposal (although I don't think the issues are exactly 
> the same for 
> > > endpoints are ECN capable, then the ECN source slows down (seems 
> > > reasonable). If they're not capable, then the impact outside the 
> > > domain isn't any different to what would happen without 
> PCN-domain.
> > >
> > > Then this will lead to either flow admission or 
> termination in the 
> > > PCN-domain. These are both safe, in that the reaction is 
> (I believe) 
> > > at least as severe as would happen in an all ECN world.
> end-to-end ECN 
> > > & PCN on the same flow really is useful, [2] the mechanism (eg 
> > > tunnelling) to carry ECN-marking transparently across the 
> PCN-domain 
> > > has also failed, [3] the flows which are terminated aren't other 
> > > ECN-11 flows that are also getting in due to the same 
> > > misconfiguration.
> > >
> > > Best wishes
> > > Phil
> network since
> problem that
> benefits too).
> I
> down much

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 10:50:29 -0000

Possible bad things that can happen:

1) 11 packets leak into PCN region through a misconfigured router that
fails to tunnel them. With the proposed coding these will be treated at
the egress as an indication of admission marking. However it is
reasonably safe for the egress router to just let them out with the
marking unchanged (see point 2 below). This is because at a conceptual
level the PCN region can simply be seen as a non-ECN router on an ECN
path (must be an ECN path for 11 to enter the region in the first
place). Passing the mark on ensures it reaches the end destination
although the presence of the mark may have marginally affected the
measurement of that aggregate within the PCN region.

2) Packets marked 11 by the PCN region leaking out. If the packets are
part of an ECN flow (which still seems very weird to me - ECN being
designed for elastic traffic and PCN being designed for inelastic), then
the packet would have carried 10 or 01 at the ingress and thus should
have been tunnelled in some fashion. If this didn't happen through some
misconfiguration then the receiver will see this as an indication of
congestion and respond accordingly. This will indeed result in PCN
traffic receiving "worse" treatment than non-PCN traffic following the
same path, however as the reason for marking was to indicate
pre-congestion and as the PCN region is principally concerned with
providing a guaranteed level of service to traffic this may not matter.
Once someone gives a really convincing explanation of why you would use
ECN on a flow that is traversing a PCN region I will accept that we need
to worry about this...

My view is that it is nearly impossible to adequately address all the
corner cases where there is some mis-configuration of the PCN region.
All that is necessary is to document them and show that they have been
adequately considered. At the end of the day there is every chance of
misconfigured routers doing strange things anyway and that is just as
true for DSCPs as for ECN.

The really key thing to consider is do we care about letting packets we
have marked 11 leak from the PCN region or should we re-set them to 00?
If they are not ECN packets then the only detrimental affects of this
are that ECN routers think they are ECN and can't use them to indicate
congestion and misconfigured receivers may think these were part of an
ECN flow. If we decide to reset them then concern 1) above does matter.

One final thought - ECN is designed with inbuilt protection - ultimately
if a router is congested it will revert to dropping packets. If this
weren't so then there would be an enormous DoS vulnerability from just
sending all packets with 11 already set...

Toby

NB very relevant text in section 8 of RFC3168:

"The first two possible changes, falsely reporting congestion or
   disabling ECN-Capability for an individual packet, are no worse than
   if the router were to simply drop the packet.  From a congestion
   control point of view, setting the CE codepoint in the absence of
   congestion by a non-compliant router would be no worse than a router
   dropping a packet unnecessarily. By "erasing" an ECT codepoint of a
   packet that is later dropped in the network, a router's actions could
   result in an unnecessary packet drop for that packet later in the
   network.

   However, as discussed in Section 18, a router that erases the ECN
   congestion indication or falsely indicates ECN-Capability could
   potentially do more damage to the flow that if it has simply dropped
   the packet.  A rogue or broken router that "erased" the CE codepoint
   in arriving CE packets would prevent that indication of congestion
   from reaching downstream receivers.  This could result in the failure
   of congestion control for that flow and a resulting increase in
   congestion in the network, ultimately resulting in subsequent packets
   dropped for this flow as the average queue size increased at the
   congested gateway."

> Sent: 21 February 2008 10:01
> To: Eardley,PL,Philip,CXR9 R
> Cc: Moncaster,T,Toby,CXR9 R; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Briscoe,RJ,Bob,CXR9 R

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 12:50:06 -0000

Thanks for pointing at this. luckily your proposal is really one option
(and not the daunting 4) - this would also enable your text to be
shortened. 

I raised several suggestions & comments with this text, on the previous
version of this draft round about the last ietf.
http://www.ietf.org/mail-archive/web/pcn/current/msg00909.html .

This had comments on the whole draft, some of which still apply,
including these on your text below:

------ extract from email of 20 nov ------------
"In addition Option 8 and 10 can in addition support the ECMP solution."
Replace: "They support Affected marking, which [ref] says has benefits
if the PCN-domain operates ECMP multi-path routing"

additional benefit (and in my view the most significant): exptal dscps
are lightly standardised - limited rules on how you use them, largely up
to the operator.

3.3.2 Drawbacks
...

Clarify that particular issue for mpls [codepoint shortage]

...

Major disadvantage: interactions with ECMP. ECMP algos can use a
packet's DSCP when deciding what interface to fwd it on. In a PCN-domain
running ECMP, for a flow which has some packets PCN-marked and some
unmarked. its packets will travel over more than one path. This may well
lead to mis-ordering. To me, this means that the S3.3 DSCP option is a
non-starter in any PCN-domain that uses an ECMP algorithm that uses the
DSCP. NB ECMP algos are proprietary to router vendors, ie operator has
poor control over them.

------- end of extract ------

in addition:
reading toby's email there are some additional points to raise:

1. extra con: router has to read the existing marking before writing
(otherwise AM can over-write TM)
2. given Toby's option has some thoughts about what happens in the event
that the PCN-boundary-nodes are misconfigured (and let 11 pkts sneak in
or out), I think it would also be fair for your option to have some
thinking about what happens if PCN-boundary-node misconfiguration allows
a "PCN DSCP" to sneak in /out. 

Phil.

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 21 February 2008 10:07
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R; [email-masked]
> wuerzburg.de; Moncaster,T,Toby,CXR9 R
> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP
4 |
|===========++==========+===========+===========+===========+===========
|
> | Option 6  || Not-PCN  |    PCN    |   AM/TM   |    NA     |    NA
|
|-----------++----------+-----------+-----------+-----------+-----------
|
> | Option 7  || Not-PCN  |    PCN    |   AM/TM   |    AfM    |    NA
|
|-----------++----------+-----------+-----------+-----------+-----------
|
> | Option 8  || Not-PCN  |    PCN    |     AM    |    TM     |    NA
|
|-----------++----------+-----------+-----------+-----------+-----------
|
> > > From: Ingemar Johansson S
[mailto:[email-masked]]
> > > for a discussion of the use cases and a motivation to why end to
end
> > ECN
> > > to see that if one wish to maintain support for end to end ECN
(not
> > only
this
> > > > > [email-masked]; [email-masked];
[email-masked];
> > > > > ECN nodes outside the PCN domain although endpoints are not
ECN
> > > > > achieve that objective. Therefore, I feel that spending two
DSCP
> > > > > > have lit upon a neat solution that seems to have lots of
pros
> > and
> > > > > >  o  Termination marking and admission marking are
independent,
> > eg
> > > > > > a flow. This may be OK as (1) no-one has yet said they know
of
> > an

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Feb 2008 14:45:16 +0100

Hi Phil

Thank you very much!

Please see in line!

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 21 februari 2008 13:50
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> Thanks for pointing at this. luckily your proposal is really 
> one option (and not the daunting 4) - this would also enable 
> your text to be shortened. 

Georgios: I think that they are 4! 
Later on the PCN-WG will make a slection of one of the 4!

> 
> I raised several suggestions & comments with this text, on 
> the previous version of this draft round about the last ietf.
> This had comments on the whole draft, some of which still 
> apply, including these on your text below:

Georgios: Thank you very much!

> 
> ------ extract from email of 20 nov ------------ "In addition 
> Option 8 and 10 can in addition support the ECMP solution."
> Replace: "They support Affected marking, which [ref] says has 
> benefits if the PCN-domain operates ECMP multi-path routing"

Georgios: Agree!

> 
> additional benefit (and in my view the most significant): 
> exptal dscps are lightly standardised - limited rules on how 
> you use them, largely up to the operator.

Georgios: Agree!

> Clarify that particular issue for mpls [codepoint shortage]
Georgios: I think that the issue is mentioned, but i will include the
ECN-MPLS 
solution.

> 
> ...
> 
> Major disadvantage: interactions with ECMP. ECMP algos can 
> use a packet's DSCP when deciding what interface to fwd it 
> on. In a PCN-domain running ECMP, for a flow which has some 
> packets PCN-marked and some unmarked. its packets will travel 
> over more than one path. This may well lead to mis-ordering. 
> To me, this means that the S3.3 DSCP option is a non-starter 
> in any PCN-domain that uses an ECMP algorithm that uses the 
> DSCP. NB ECMP algos are proprietary to router vendors, ie 
> operator has poor control over them.

Georgios: This will be a disadvantage only if ECMP based on DSCP is widely
used.
From the discussion that we have had, e.g., Rudiger, this ECMP option is 
not deployed in large scale.
However, I can mention that if ECMP based on DSCP is used that this might
cause
reotrdering problems.

> 1. extra con: router has to read the existing marking before 
> writing (otherwise AM can over-write TM) 2. given Toby's 
> option has some thoughts about what happens in the event that 
> the PCN-boundary-nodes are misconfigured (and let 11 pkts 
> sneak in or out), I think it would also be fair for your 
> option to have some thinking about what happens if 
> PCN-boundary-node misconfiguration allows a "PCN DSCP" to 
> sneak in /out. 

Georgios: I think that the issue of what happens if 
a PCN-boundary-node misconfiguration allows a "PCN DSCP" to 
sneak in /out does not cause any problem for the DSCP based options, because

when no agreements exist between two neighboring PCN domains the 
PCN-ingress-node will have to remark all incoming packets to the DSCP value
used for PCN capable not congested (PCN) indication. 

Best regards,
Georgios

> > In my opinion the goal of the encoding draft is to provide this 
> > information to the PCN-WG.
> > Phil and Ingemar, if you can add advantages, disadvantages 
> to the ones 
> > already mentioned below in Section 3.2.1 and 3.2.2 of the
> encoding
> > draft, please do.
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> > | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 
> |Add DSCP
> 4 |
> >
> >    value of this DSCP/PHB can either follow a standards 
> action or use
> a
> > > I believe that the emails below about Toby's encoding proposal do 
> > > indeed already consider ECN. Would appreciate it if you could add 
> > > further text to it to better capture the (pros and) cons.
> > >
> > > > more DSCP codepoints
> > > setting out this option with its pros and cons (ie 
> similar to what 
> > > toby has done below) is needed I think! At the moment we 
> have lots 
> > > of options on the table - in order to reach a decision, I 
> think we 
> > > really need very few options but with their pros and cons better 
> > > laid out.
> > >
> > >
> > > > broken if a PCN encoding option "fiddles" with the ECN 
> bits. It is
> > > easy
> > > > together so much the better even though the cost e.g in 
> DSCP code
> > > points
> > > > is regarded as higher.
> > > >
> > > > Regards
> > > > Ingemar
> > > >
> > > > > > From: Michael Menth 
> [mailto:[email-masked]]
> > > > > > > safest option if packets leak outside the PCN 
> region, due to
> > > some
> > > > > fort
> > > > > > > skews the results and causes significant 
> over-termination or
> > > not.
> > > > > > >
> > > > > > > have a similar "one page" email about a specific 
> scheme that
> > > only
> > > > > uses

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 21 Feb 2008 14:47:11 +0100

Hi

Putting the issues with "leakage" aside (I cannot tell how serious this
problem really is). 

I would prefer to sacrifice the end to end ECN semantics for the ECT(0)
and ECT(1) codepoints instead of the ECN-CE codepoint. The reason is
simply that from a realtime communication scenario with out of band
signaling it is always possible to negotiate the use of ECN CE mark in
wireless nodes by means of eg. SIP signaling. Also, atleast for RTP/UDP
I see little use for ECN nonce like it is done with TCP as this is more
or less an anti-cheat feature.

One would then end up with a PCN encoding schema like (I beleve option 5
in figure 1 in the PCN encoding draft) is the closest.

PCN Meaning		ECN 	 DSCP
=============================
PCN capable		00	 PCN 1
Admission Mark	01	 PCN 1
Termination Mark	10	 PCN 1

At PCN ingress the ECT(0) and ECT(1) codepoints should be set to "00",
likewise at PCN egress. ECN CE is however left untouched. This has the
effect that routers will be able to set ECN-CE on packets before they
enter the first PCN domain, after exit from the PCN domain  routers are
not anymore allowed to set ECN-CE (RFC4774 section 4.3). Wireless nodes
such as LTE-eNB (Long Term Evolution-Enhanced Node B) can however set
ECN CE as this is can be managed by out of band signaling.

Besides this I would prefer a solution that maintains end to end
semantics regardless of DSCP value. If one consider DCCP we don't know
today if it will be a best effort traffic alternatiive or if there is a
benefit with it even with QoS and DCCP can use ECN nonce.

/Ingemar

> Sent: den 21 februari 2008 11:07
> To: [email-masked]; Ingemar Johansson S
> In order to make a selection of one single (or two) options, 
> I think that the PCN WG should get the possibility to study 
> all the possible and PCN relevant encoding options.
> 
> In my opinion the goal of the encoding draft is to provide 
> this information to the PCN-WG.
> Based on this information the PCN WG can discuss and decide 
> which of the options should be used.
> 
> Please note that the encoding draft should list all relevant 
> options with advantages and disadvantages. 
> 
> Phil and Ingemar, if you can add advantages, disadvantages to 
> the ones already mentioned below in Section 3.2.1 and 3.2.2 
> of the encoding draft, please do.
> 
> Best regards,
> Georgios
> 
> 
> 
> |Add DSCP 4 
> || 
> ===========++==========+===========+===========+===========+==
> =========|
> action or use a
> codepoints 
> > (as has Georgios). That's fine - but a "1 pager"
> > setting out this option with its pros and cons (ie similar to what 
> have lots of 
> > options on the table - in order to reach a decision, I 
> think we really 
> > need very few options but with their pros and cons better laid out.
> > 
> > 
> > > for a discussion of the use cases and a motivation to why 
> end to end
> > ECN
> > > to see that if one wish to maintain support for end to 
> end ECN (not
> > only
> expensive 
> > > > > > have lit upon a neat solution that seems to have 
> lots of pros
> > and
> > > > few
> > > > > > a flow. This may be OK as (1) no-one has yet said 
> they know of
> > an
> > > > ECMP

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 14:18:21 -0000

> Later on the PCN-WG will make a slection of one of the 4!

Well, we have a decision about how many codepoints to support, and we
have a decision about how to support this number of codepoints. 
So: we look at the 4 encodings option, in order to compare it with
toby's email.

> However, I can mention that if ECMP based on DSCP is used that this
might

As far as I remember, the entire input on whether ecmp algorithms
actually use dscp was the following email from Rudiger [22nov]:
"true, the DSCP shouldn't be used to influence ECMP decissions. IP
adresses and may be ports. I'd have to ask my staff to get 
details. I've no problem to recommend not to base ECMP 
decisions on DSCPs. "
please can you point at other emails I missed about " this ECMP option
is not deployed in large scale", as I'd be very interested in this. 

so: it is clear that in theory ecmp algorithms may use dscp value, and
that at the moment we don't know in practice or whether there are vendor
plans to do so in the future. 

> > writing (otherwise AM can over-write TM) 

please remember this con.

2. given Toby's
> used for PCN capable not congested (PCN) indication.

To clarify: I was saying there should be text (not whether it was a con)

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 21 Feb 2008 15:23:22 +0100

Hi Georgios, 

unfortunately the ECMP issue is less simple than assumed. Solutions implemented by 
a single vendor or for a specific protocol don't have to work for other vendors, 
protocols and may even change with operation systems or hardware platforms of 
the same vendor.

Unless you have spoken with your backbone vendors or even better, unless you have 
standardised it, you can't for sure say that vendors don't use DSCPs for ECMP. 

Using IP adresses for the purpose of ECMP is very popular however, that's true. 
Also the IETF assumes that many routers do that.

Regards,

Ruediger

| > ...
| > 
| > Major disadvantage: interactions with ECMP. ECMP algos can use a 
| > packet's DSCP when deciding what interface to fwd it on. In a 
| > PCN-domain running ECMP, for a flow which has some packets PCN-marked 
| > and some unmarked. its packets will travel over more than one path. 
| > This may well lead to mis-ordering.
| > To me, this means that the S3.3 DSCP option is a non-starter in any 
| > PCN-domain that uses an ECMP algorithm that uses the DSCP. NB ECMP 
| > algos are proprietary to router vendors, ie operator has poor control 
| > over them.
| 
| Georgios: This will be a disadvantage only if ECMP based on 
| DSCP is widely used.
| From the discussion that we have had, e.g., Rudiger, this 
| ECMP option is not deployed in large scale.
| However, I can mention that if ECMP based on DSCP is used 
| that this might cause reotrdering problems.
|
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Feb 2008 15:30:59 +0100

Hi Phil

Please see in line!

> Sent: donderdag 21 februari 2008 15:18
> Well, we have a decision about how many codepoints to 
> support, and we have a decision about how to support this 
> number of codepoints. 
> So: we look at the 4 encodings option, in order to compare it 
> with toby's email.

Georgios: You mean Toby and you had a decission!

> > > packet's DSCP when deciding what interface to fwd it on. In a 
> > > PCN-domain running ECMP, for a flow which has some packets 
> > > PCN-marked and some unmarked. its packets will travel 
> over more than 
> > > one path. This may well lead to mis-ordering.
> > > To me, this means that the S3.3 DSCP option is a 
> non-starter in any 
> > > PCN-domain that uses an ECMP algorithm that uses the 
> DSCP. NB ECMP 
> > > algos are proprietary to router vendors, ie operator has poor 
> > > control over them.
> > 
> > From the discussion that we have had, e.g., Rudiger, this 
> ECMP option
> is
> As far as I remember, the entire input on whether ecmp 
> algorithms actually use dscp was the following email from 
> Rudiger [22nov]:
> "true, the DSCP shouldn't be used to influence ECMP 
> decissions. IP adresses and may be ports. I'd have to ask my 
> staff to get details. I've no problem to recommend not to 
> base ECMP decisions on DSCPs. "
> please can you point at other emails I missed about " this 
> ECMP option is not deployed in large scale", as I'd be very 
> interested in this. 
> 
> so: it is clear that in theory ecmp algorithms may use dscp 
> value, and that at the moment we don't know in practice or 
> whether there are vendor plans to do so in the future. 

Georgios: I am not sure if this is the email that encaptured that
discussion. 
It will be good if we can get more input from operators on the usage of DSCP
for ECMP.
However, as I already mentioned, a sentence associated with this issue can
be included in the text!

> please remember this con.

Georgios: I do not understand this statement! A router has to know what it
has
to mark and how. Or am I missing something here? The same holds for 
marking ECN bits!

> 
> 2. given Toby's
> > > option has some thoughts about what happens in the event that the 
> > > PCN-boundary-nodes are misconfigured (and let 11 pkts sneak in or 
> > > out), I think it would also be fair for your option to have some 
> > > thinking about what happens if PCN-boundary-node misconfiguration 
> > > allows a "PCN DSCP" to sneak in /out.
> > 
> > Georgios: I think that the issue of what happens if a 
> > PCN-boundary-node misconfiguration allows a "PCN DSCP" to sneak in 
> > /out does not cause any problem for the DSCP based options, because
> > 
> > PCN-ingress-node will have to remark all incoming packets 
> to the DSCP 
> > value used for PCN capable not congested (PCN) indication.
> 

Best regards,
Georgios

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 14:33:57 -0000

Hi Ingemar,

This is exactly the sort of thing Phil and I were hoping to trigger
people to write in response to our email. We are hoping to settle on
what are the real options people support for the encoding and why they
support them...

Just one quick observation - if we have to leave 11 unchanged across the
PCN domain this will mean that such packets can't be PCN marked and thus
they should not form part of any PCN aggregate (in my opinion)...

Toby

> Sent: 21 February 2008 13:47
> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R; 
> [email-masked]; Moncaster,T,Toby,CXR9 R

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 14:37:19 -0000

Please see inline 

> Sent: 21 February 2008 14:31

Toby: From minutes of IETF 70:

"Need to say that range of states required is 3 to 5. Agreed."

The actual discussion was that the states needed were a selection of 3 4
or 5 states from not PCN, PCN capable, Admission Mark (or equiv),
Termination Mark (or equiv) and Affected Mark. Ignoring the Not Pcn
state (as this is a separate issue) this leaves the 4 encodings Phil is
referring to

> > > Georgios: This will be a disadvantage only if ECMP based 
> on DSCP is
> > widely
> > > used.
> > > However, I can mention that if ECMP based on DSCP is used 
> that this
> > might
> > > cause
> > > reotrdering problems.
> > 
> sneak in

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 14:49:13 -0000

> Georgios: You mean Toby and you had a decission!

I meant this. my brain cannot hold all debates simultaneously. So: have
the discussion about how many different encoding states are needed. Have
the discussion about how you encode each of those states. Toby's email
assumes all 4 states are needed. 

In any case - is there really any substantive difference, in terms of
pros and cons, between your 4 options? They're all "just use as many
dscps as required", and all have similar pros and cons surely?

> to mark and how. Or am I missing something here? The same holds for

is whether the router has to check what the pkt's marking is before it
marks it. with your scheme it does. As toby's email: " (Note:
Over-writing a TM with AM is not allowed for 3SM & CL, see
draft-charny-pcn-comparison.)"

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Feb 2008 16:18:41 +0100

Hi Toby

 > "Need to say that range of states required is 3 to 5. Agreed."

The sentence above mentiones that it has to be said
how many number of states an option requires: 3, 4 or 5.

It does not say anything about the selection of 
an option that supports 4 states!
 Or am I missing something here!

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 21 februari 2008 15:37
> To: [email-masked]; [email-masked]; 
> [email-masked]
> [email-masked]
> support, and 
> > > we have a decision about how to support this number of codepoints.
> The actual discussion was that the states needed were a 
> selection of 3 4 or 5 states from not PCN, PCN capable, 
> Admission Mark (or equiv), Termination Mark (or equiv) and 
> Affected Mark. Ignoring the Not Pcn state (as this is a 
> separate issue) this leaves the 4 encodings Phil is referring to
> 
> 
> > > 
> > > > > ...
> > > > >
> decissions. IP 
> > > adresses and may be ports. I'd have to ask my staff to 
> get details. 
> > > I've no problem to recommend not to base ECMP decisions 
> on DSCPs. "
> > > please can you point at other emails I missed about " this ECMP 
> > > option is not deployed in large scale", as I'd be very 
> interested in 
> > > this.
> > > 
> > > so: it is clear that in theory ecmp algorithms may use 
> dscp value, 
> > > and that at the moment we don't know in practice or whether there 
> > > are vendor plans to do so in the future.
> > 
> > It will be good if we can get more input from operators on 
> the usage 
> > of DSCP for ECMP.
> > However, as I already mentioned, a sentence associated with 
> this issue 
> > can be included in the text!
> > 
> > 
> > 
> > > 
> > > 
> > > > >
> > Georgios: I do not understand this statement! A router has to know 
> > what it has to mark and how. Or am I missing something 
> here? The same 
> > holds for marking ECN bits!
> > 
> > 
> > > 
> > > 2. given Toby's
> > > To clarify: I was saying there should be text (not 
> whether it was a 
> > > con)
> > 
> > Best regards,
> > Georgios
> > 
> > > 
> > > 
> > 
> > 
> > 
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 21 Feb 2008 17:17:46 +0100

Hi Georgios,

I copy one statement from below:

| Georgios: I am not sure if this is the email that encaptured 
| that discussion. 
| It will be good if we can get more input from operators on 
| the usage of DSCP for ECMP.
[snip]

You should look for that input from vendors. Operators have the 
choice to activate or deactivate ECMP. They can't configure it 
(at least not with the systems from our vendors).

Regards,

Ruediger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of Georgios Karagiannis
| Sent: Thursday, February 21, 2008 3:31 PM
| To: [email-masked]; [email-masked]
| Cc: [email-masked]; [email-masked]
| Subject: Re: [PCN] FW: RE: PCN encoding option
| 
| Hi Phil
| 
| Please see in line!
|  
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]]
| > Sent: donderdag 21 februari 2008 15:18
| > To: [email-masked]; [email-masked]
| > Cc: [email-masked]; [email-masked]; 
| > [email-masked]; [email-masked]
| > Subject: RE: [PCN] FW: RE: PCN encoding option
| > 
| > > 
| > > Georgios: I think that they are 4!
| > > Later on the PCN-WG will make a slection of one of the 4!
| > 
| > Well, we have a decision about how many codepoints to 
| support, and we 
| > have a decision about how to support this number of codepoints.
| > So: we look at the 4 encodings option, in order to compare it with 
| > toby's email.
| 
| Georgios: You mean Toby and you had a decission!
| 
| > 
| > > > ...
| > > >
| > > > Major disadvantage: interactions with ECMP. ECMP algos 
| can use a 
| > > > packet's DSCP when deciding what interface to fwd it on. In a 
| > > > PCN-domain running ECMP, for a flow which has some packets 
| > > > PCN-marked and some unmarked. its packets will travel
| > over more than
| > > > one path. This may well lead to mis-ordering.
| > > > To me, this means that the S3.3 DSCP option is a
| > non-starter in any
| > > > PCN-domain that uses an ECMP algorithm that uses the
| > DSCP. NB ECMP
| > > > algos are proprietary to router vendors, ie operator has poor 
| > > > control over them.
| > > 
| > > Georgios: This will be a disadvantage only if ECMP based 
| on DSCP is
| > widely
| > > used.
| > > From the discussion that we have had, e.g., Rudiger, this
| > ECMP option
| > is
| > > not deployed in large scale.
| > > However, I can mention that if ECMP based on DSCP is used 
| that this
| > might
| > > cause
| > > reotrdering problems.
| > 
| > As far as I remember, the entire input on whether ecmp algorithms 
| > actually use dscp was the following email from Rudiger [22nov]:
| > "true, the DSCP shouldn't be used to influence ECMP decissions. IP 
| > adresses and may be ports. I'd have to ask my staff to get details. 
| > I've no problem to recommend not to base ECMP decisions on DSCPs. "
| > please can you point at other emails I missed about " this 
| ECMP option 
| > is not deployed in large scale", as I'd be very interested in this.
| > 
| > so: it is clear that in theory ecmp algorithms may use dscp 
| value, and 
| > that at the moment we don't know in practice or whether there are 
| > vendor plans to do so in the future.
| 
| Georgios: I am not sure if this is the email that encaptured 
| that discussion. 
| It will be good if we can get more input from operators on 
| the usage of DSCP for ECMP.
| However, as I already mentioned, a sentence associated with 
| this issue can be included in the text!
| 
| 
| 
| > 
| > 
| > > >
| > > > 1. extra con: router has to read the existing marking
| > before writing
| > > > (otherwise AM can over-write TM)
| > 
| > please remember this con.
| 
| Georgios: I do not understand this statement! A router has to 
| know what it has to mark and how. Or am I missing something 
| here? The same holds for marking ECN bits!
| 
| 
| > 
| > 2. given Toby's
| > > > option has some thoughts about what happens in the 
| event that the 
| > > > PCN-boundary-nodes are misconfigured (and let 11 pkts 
| sneak in or 
| > > > out), I think it would also be fair for your option to 
| have some 
| > > > thinking about what happens if PCN-boundary-node 
| misconfiguration 
| > > > allows a "PCN DSCP" to sneak in /out.
| > > 
| > > Georgios: I think that the issue of what happens if a 
| > > PCN-boundary-node misconfiguration allows a "PCN DSCP" to 
| sneak in 
| > > /out does not cause any problem for the DSCP based 
| options, because
| > > 
| > > when no agreements exist between two neighboring PCN domains the 
| > > PCN-ingress-node will have to remark all incoming packets 
| > to the DSCP 
| > > value used for PCN capable not congested (PCN) indication.
| > 
| > To clarify: I was saying there should be text (not whether it 
| > was a con)
| 
| Best regards,
| Georgios
| 
| > 
| > 
| 
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| http://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: Lars Eggert <[email-masked]>
Date: Thu, 21 Feb 2008 18:55:52 +0200

Hi,

just a quick reminder that any use of the ECN bits by PCN absolutely  
must conform to RFC4774.

Lars

---

From: Michael Menth <[email-masked]>
Date: Fri, 22 Feb 2008 08:13:22 +0100

Hi Toby,

> they should not form part of any PCN aggregate (in my opinion)...

I find they should be metered, but never remarked.

Regards,

    Michael

>>>    precongestion information is encoded into the 6 DSCP 
>>>       
>> bits that are
>>     
>>>    alternatives can be distinguished, as can be seen in 
>>>       
>> Figure 3, with
>>     
>>>    Option 7 needs 2 additional DSCP values, Options 8 and 9 
>>>       
>> need three
>>     
>>>    values.  Note that all additional and experimental DSCP 
>>>       
>> values are
>>     
>>>    the end-to-end ECN semantics and therefore the issues 
>>>       
>> and concerns
>>     
>>>    termination (TM) encoding states.  In addition Option 8 
>>>       
>> and 10 can
>>     
>>>    original DSCP and depending on the encoding option used, 
>>>       
>> one, two,
>>     
>>>    DSCP values are representing and are associated with one 
>>>       
>> PHB.  The
>>     
>>> Behalf Of 
>>>> [email-masked]
>>>> need very few options but with their pros and cons better 
>>>>         
>> laid out.
>>     
>>>>> In this discussion it may be well worth the effort to
>>>>>           
>>>> consider the end
>>>>         
>>>>> to end ECN usecases that we foresee when considering 
>>>>>           
>> various PCN 
>>     
>>>>> encoding options.
>>>>> Please have a look at
>>>>>
>>>>>           
>>>>> should be maintained even across PCN nodes even for non 
>>>>>           
>>> DF traffic.
>>>       
>>>>> That said I realize that there is some cost associated to
>>>>>           
>>>> the use of
>>>>         
>>>>> DSCP codepoints, this cost must however be weighted against
>>>>>           
>>>> the risk
>>>>         
>>>>> that other functionality like end to end ECN semantics is 
>>>>>           
>>> probably 
>>>       
>>>>> I am not explicitly saying don't do this or that but I wish
>>>>>           
>>>> to avoid a
>>>>         
>>>>> it may in the end prevent deployment of both. If one can
>>>>>           
>>>> yank the two
>>>>         
>>>>>> (not two, as one is spent anyway). I think the only way 
>>>>>>             
>>> of really 
>>>       
>>>>>> assessing this properly is for an alternative proposal 
>>>>>>             
>>> (with pros 
>>>       
>>>>>> encoding lies. Personally I have no axe to grind for 
>>>>>>             
>> or against 
>>     
>>>>>> the way to go, until compared it in detail with other 
>>>>>>             
>> proposals.
>>     
>>>> Philadelphia
>>>>>> You're correct about one of the motivations 
>>>>>>             
>>> (advantages) for this 
>>>       
>>>> the same for
>>>>>> 11 leakage as 01/10 leakage).
>>>>>>
>>>>>> Consider the case where 11 leaks out of the PCN 
>>>>>>             
>> domain. If the 
>>     
>>>>>> endpoints are ECN capable, then the ECN source slows 
>>>>>>             
>>> down (seems 
>>>       
>>>>>> reasonable). If they're not capable, then the impact 
>>>>>>             
>>> outside the 
>>>       
>>>>>> has also failed, [3] the flows which are terminated 
>>>>>>             
>> aren't other
>>     
>>>>>>> Cc: [email-masked]; Eardley,PL,Philip,CXR9 R; 
>>>>>>>               
>>> [email-masked]; 
>>>       
>>>>>>> as I understand the proposal, the motivation is to 
>>>>>>>               
>>> avoid 01/10 
>>>       
>>>>>>> the same problem with 11 marking, i.e. 11-packets may not be
>>>>>>>               
>>>> dropped
>>>>         
>>>>>> by
>>>>>>             
>>>>>>> ECN nodes outside the PCN domain although endpoints 
>>>>>>>               
>>> are not ECN
>>>       
>>>>>> capable.
>>>>>>             
>>>>>>> achieve that objective. Therefore, I feel that 
>>>>>>>               
>>> spending two DSCP
>>>       
>>>>>> values
>>>>>>             
>>>>>>> is quite expensive.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>     Michael
>>>>>>>
>>>>>>>> through the simplified version without Affected 
>>>>>>>>                 
>>> marking first:
>>>       
>>>>>>>> PCN Meaning		ECN 	 DSCP
>>>>>>>>
>>>>>>>> PCN capable		00	 PCN 1
>>>>>>>> Admission Mark	11	 PCN 1
>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with 
>>>>>>>>                 
>> the same PCN
>>     
>>>>>> behaviour
>>>>>>             
>>>>>>>> aggregate.
>>>>>>>>
>>>>>>>> Pros:
>>>>>>>> termination marking can be done after a packet has been
>>>>>>>>                 
>>>> admission
>>>>         
>>>>>>>> packet's PCN marking first, which is easier to
>>>>>>>>                 
>>>> implement. (Note:
>>>>         
>>>>>>>> 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.
>>>>         
>>>>>>>> o  Incremental deployment steps are possible [1]
>>>>>>>>                 
>>>> could deploy SM
>>>>         
>>>>>>>> If a router isn't upgraded at the same time nothing
>>>>>>>>                 
>>>> too horrific
>>>>         
>>>>>>>> happens.
>>>>>>>> [2] could just deploy admission control & add
>>>>>>>>                 
>>>> termination later,
>>>>         
>>>>>> just by
>>>>>>             
>>>>>>>> o  It needs an extra DSCP, per PCN behaviour aggregate.
>>>>>>>>                 
>>>> (Although
>>>>         
>>>>>>>> possibly it's OK to use the same DSCP for TM for 
>>>>>>>>                 
>>> all PCN BAs?)
>>>       
>>>>>>>> DSCP to select routes, then there may be mis-ordering
>>>>>>>>                 
>>>> of packets
>>>>         
>>>>>> within
>>>>>>             
>>>>>>>> If Affected marking is needed then the scheme can be
>>>>>>>>                 
>>>> modified as
>>>>         
>>>>>>>> follows:
>>>>>>>>
>>>>>>>> PCN Meaning		ECN 	DSCP
>>>>>>>>
>>>>>>>> PCN capable		00	PCN 1
>>>>>>>> Admission Mark	11	PCN 1
>>>>>>>> The pros for this scheme are broadly similar to the above.
>>>>>>>>                 
>>>> However
>>>>         
>>>>>> there
>>>>>>             
>>>>>>>> Please could people look through this scheme and
>>>>>>>>                 
>>>> highlight any
>>>>         
>>>>>>>> scheme instead". Currently we seem to have a plethora of
>>>>>>>>                 
>>>> possible
>>>>         
>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
>>>>>>>>                 
>> 1473 648734
>>     
>>>>>>> --
>>>>>>> Dr. Michael Menth, Assistant Professor University of 
>>>>>>>               
>>> Wuerzburg, 
>>>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 22 Feb 2008 08:44:46 +0100

Hi Phil, hi Georgios, 

a misconfigured router could let some DSCPs or ECN codepoints slip out 
and another misconfigured router could let the very same packets slip 
in without a change. This is all ugly.

I'd prefer discussions like this to be dropped. Misconfigurations may 
end with ugly things. If they are dangerous, there should be no 
configuration options (an example related to the subject: once a router 
talks BGP on an interface, it will never forward a PCN coloured 
packet across that interface. If this policy is supposed to change 
and misconfigs should be avoided, one could ask particular BGP based 
solutions to signal and enable PCN by that on the interface and so on).

Regards,

Ruediger

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 22 Feb 2008 09:22:32 +0100

Hi

Answers inline 

> Sent: den 21 februari 2008 15:34
> To: Ingemar Johansson S; [email-masked]; [email-masked]
> This is exactly the sort of thing Phil and I were hoping to 
> trigger people to write in response to our email. We are 
> hoping to settle on what are the real options people support 
> for the encoding and why they support them...
> 
> Just one quick observation - if we have to leave 11 unchanged 
> across the PCN domain this will mean that such packets can't 
> be PCN marked and thus they should not form part of any PCN 
> aggregate (in my opinion)...

Realized that this is one (big) problem, thanks for pointing out this
issue.

The next alternative is then
PCN Meaning		 ECN 	 DSCP
=============================
PCN capable		 00    PCN 1
Admission Mark	 01	 PCN 1
Termination Mark	 10	 PCN 1

PCN capable+ECN CE 00    PCN 2
AM+ECN CE     	 01	 PCN 2
TM+ECN CE     	 10	 PCN 2

I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN egress PCN 2
is mapped back to the ECN bits as ECN-CE "11".

AfM can also be included in the schema 

I know this does cost an extra DSCP codepoint and it completely
disregards the leakage issue, also it possible that this alternative or
something similar is given in the PCN encoding draft but I don't think
so as this alternative does not preserve the end to end ECN semantics to
100%, rather it assumes that negotiation of the use of ECN is done out
of band at session setup.

/Ingemar

> > Putting the issues with "leakage" aside (I cannot tell how serious 
> > this problem really is).
> > 
> > I would prefer to sacrifice the end to end ECN semantics for the 
> > ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The 
> > reason is simply that from a realtime communication 
> scenario with out 
> > of band signaling it is always possible to negotiate the 
> use of ECN CE 
> > mark in wireless nodes by means of eg. SIP signaling. Also, atleast 
> > for RTP/UDP I see little use for ECN nonce like it is done 
> with TCP as 
> > this is more or less an anti-cheat feature.
> >  
> > 
> proposal do

---

From: Michael Menth <[email-masked]>
Date: Fri, 22 Feb 2008 10:13:21 +0100

Hi Ingemar,

this solution essentially spends a DSCP to save 11-marking through the 
PCN domain and allow them to be PCN-marked. This is a rather high price, 
in particular because the PCN packets need to be remarked to 00. This 
has the consequence that ECN capability is lost for the rest of the path.

Therefore, I opt for one of the two versions
1) discard 11-marked PCN packets before entering the PCN domain OR
2) let them go through the PCN domain, take them into account for 
metering, but do not remark them.
The first option loses ECN capability for PCN traffic, the second option 
keeps it on the subpath before entering the PCN domain.

Regards,

    Michael

Ingemar Johansson S wrote:
>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be 
>>>       
>> set to "00",
>>     
>>> likewise at PCN egress. ECN CE is however left untouched. 
>>>       
>> This has the
>>     
>>> effect that routers will be able to set ECN-CE on packets 
>>>       
>> before they
>>     
>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can 
>>>       
>> however set
>>     
>>> semantics regardless of DSCP value. If one consider DCCP we 
>>>       
>> don't know
>>     
>>>>    In this type of encoding and transport method the 
>>>>         
>> congestion and
>>     
>>>>    transported in the IP header of the data packets.  
>>>>         
>> Four possible
>>     
>>>>    representing and are associated with the same PHB.  
>>>>         
>> The 1st, 2nd,
>>     
>>>>    three, or four DSCP values, respectively.  These 
>>>>         
>> additional DSCP
>>     
>>>>    values can be taken from the DSCP values that are not 
>>>>         
>> defined by
>>     
>>>>    standards action, see RFC 2211 [9].  Note that all the 
>>>>         
>> additional
>>     
>>>>> indeed already consider ECN. Would appreciate it if you 
>>>>>           
>> could add 
>>     
>>>>>> To: Eardley,PL,Philip,CXR9 R; 
>>>>>>             
>> [email-masked];
>>     
>>>>>> Moncaster,T,Toby,CXR9 R
>>>>>>> Then we can see where the consensus for the best 
>>>>>>>               
>> (/least bad) 
>>     
>>>>>>> So I think it would be really useful to have a "1 
>>>>>>>               
>> pager" for 
>>     
>>>>>>> alternative
>>>>>>> & PCN on the same flow really is useful, [2] the 
>>>>>>>               
>> mechanism (eg
>>     
>>>>>>>> the same problem with 11 marking, i.e. 11-packets 
>>>>>>>>                 
>> may not be
>>     
>>>>> dropped
>>>>>           
>>>>>>> by
>>>>>>>               
>>>>>>>> exactly the marked flow going over an overloaded 
>>>>>>>>                 
>> ECN node is
>>     
>>>>>>> terminated.
>>>>>>>               
>>>>>>>>> Over-writing a TM with AM is not allowed for 
>>>>>>>>>                   
>> 3SM & CL, see
>>     
>>>>>>>>> This is probably easier than checking both its 
>>>>>>>>>                   
>> DSCP & ECN
>>     
>>>>> fields.
>>>>>           
>>>>>>>>> o  If a packet (in a PCN flow) arrives at the 
>>>>>>>>>                   
>> egress with
>>     
>>>>>>> its ECN =
>>>>>>> 11
>>>>>>>               
>>>>>>>>> and it really is required to preserve this info 
>>>>>>>>>                   
>> across the
>>     
>>>>>>> PCN-domain,
>>>>>>>               
>>>>>>>>> The pros for this scheme are broadly similar to 
>>>>>>>>>                   
>> the above.
>>     
>>>>> However
>>>>>           
>>>>>>> there
>>>>>>>               
>>>>>>>>> affected mark to a termination mark. Work would 
>>>>>>>>>                   
>> be needed
>>     
>>>>>>> to see if
>>>>>>> this
>>>>>>>               
>>>>>>>>> pros and cons for the schemes they support... 
>>>>>>>>>                   
>> So it could
>>     
>>>>>>> be good to
>>>>>>>               
>>>>>>>>> Toby Moncaster, <[email-masked]> 
>>>>>>>>>                   
>> Networks Research
>>     
>>>>>>> Centre, BT
>>>>>>>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 22 Feb 2008 10:39:38 +0100

Hi Michael,

I support your views and prefer 2), as it seems more user friendly.

Regards, Ruediger 

| -----Original Message-----
| From: Michael Menth [mailto:[email-masked]] 
| Sent: Friday, February 22, 2008 10:13 AM
| To: Ingemar Johansson S
| Cc: [email-masked]; [email-masked]
| Subject: Re: [PCN] FW: RE: PCN encoding option
| 
| Hi Ingemar,
| 
| this solution essentially spends a DSCP to save 11-marking 
| through the PCN domain and allow them to be PCN-marked. This 
| is a rather high price, in particular because the PCN packets 
| need to be remarked to 00. This has the consequence that ECN 
| capability is lost for the rest of the path.
| 
| Therefore, I opt for one of the two versions
| 1) discard 11-marked PCN packets before entering the PCN domain OR
| 2) let them go through the PCN domain, take them into account 
| for metering, but do not remark them.
| The first option loses ECN capability for PCN traffic, the 
| second option keeps it on the subpath before entering the PCN domain.
| 
| Regards,
| 
|     Michael
| 
| Ingemar Johansson S wrote:
| > Hi
| >
| > Answers inline
| >
| >   
| >> -----Original Message-----
| >> From: [email-masked] [mailto:[email-masked]]
| >> Sent: den 21 februari 2008 15:34
| >> To: Ingemar Johansson S; [email-masked]; 
| >> [email-masked]
| >> Cc: [email-masked]; [email-masked]; 
| >> [email-masked]
| >> Subject: RE: [PCN] FW: RE: PCN encoding option
| >>
| >> Hi Ingemar,
| >>
| >> This is exactly the sort of thing Phil and I were hoping 
| to trigger 
| >> people to write in response to our email. We are hoping to 
| settle on 
| >> what are the real options people support for the encoding and why 
| >> they support them...
| >>
| >> Just one quick observation - if we have to leave 11 
| unchanged across 
| >> the PCN domain this will mean that such packets can't be 
| PCN marked 
| >> and thus they should not form part of any PCN aggregate (in my 
| >> opinion)...
| >>     
| >
| > Realized that this is one (big) problem, thanks for 
| pointing out this 
| > issue.
| >
| > The next alternative is then
| > PCN Meaning		 ECN 	 DSCP
| > =============================
| > PCN capable		 00    PCN 1
| > Admission Mark	 01	 PCN 1
| > Termination Mark	 10	 PCN 1
| >
| > PCN capable+ECN CE 00    PCN 2
| > AM+ECN CE     	 01	 PCN 2
| > TM+ECN CE     	 10	 PCN 2
| >
| > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN 
| egress PCN 
| > 2 is mapped back to the ECN bits as ECN-CE "11".
| >
| > AfM can also be included in the schema
| >
| > I know this does cost an extra DSCP codepoint and it completely 
| > disregards the leakage issue, also it possible that this 
| alternative 
| > or something similar is given in the PCN encoding draft but I don't 
| > think so as this alternative does not preserve the end to end ECN 
| > semantics to 100%, rather it assumes that negotiation of the use of 
| > ECN is done out of band at session setup.
| >
| > /Ingemar
| >
| >  
| >   
| >> Toby
| >>
| >>     
| >>> -----Original Message-----
| >>> From: Ingemar Johansson S 
| [mailto:[email-masked]]
| >>> Sent: 21 February 2008 13:47
| >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R
| >>> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R; 
| >>> [email-masked]; Moncaster,T,Toby,CXR9 R
| >>> Subject: RE: [PCN] FW: RE: PCN encoding option
| >>>
| >>> Hi
| >>>
| >>> Putting the issues with "leakage" aside (I cannot tell 
| how serious 
| >>> this problem really is).
| >>>
| >>> I would prefer to sacrifice the end to end ECN semantics for the
| >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE codepoint. The 
| >>> reason is simply that from a realtime communication
| >>>       
| >> scenario with out
| >>     
| >>> of band signaling it is always possible to negotiate the
| >>>       
| >> use of ECN CE
| >>     
| >>> mark in wireless nodes by means of eg. SIP signaling. 
| Also, atleast 
| >>> for RTP/UDP I see little use for ECN nonce like it is done
| >>>       
| >> with TCP as
| >>     
| >>> this is more or less an anti-cheat feature.
| >>>  
| >>>
| >>> One would then end up with a PCN encoding schema like (I beleve 
| >>> option 5 in figure 1 in the PCN encoding draft) is the closest.
| >>>
| >>> PCN Meaning		ECN 	 DSCP
| >>> =============================
| >>> PCN capable		00	 PCN 1
| >>> Admission Mark	01	 PCN 1
| >>> Termination Mark	10	 PCN 1
| >>>
| >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be
| >>>       
| >> set to "00",
| >>     
| >>> likewise at PCN egress. ECN CE is however left untouched. 
| >>>       
| >> This has the
| >>     
| >>> effect that routers will be able to set ECN-CE on packets
| >>>       
| >> before they
| >>     
| >>> enter the first PCN domain, after exit from the PCN 
| domain routers 
| >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3).
| >>> Wireless nodes
| >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can
| >>>       
| >> however set
| >>     
| >>> ECN CE as this is can be managed by out of band signaling.
| >>>
| >>> Besides this I would prefer a solution that maintains end to end 
| >>> semantics regardless of DSCP value. If one consider DCCP we
| >>>       
| >> don't know
| >>     
| >>> today if it will be a best effort traffic alternatiive or 
| if there 
| >>> is a benefit with it even with QoS and DCCP can use ECN nonce.
| >>>
| >>> /Ingemar
| >>>
| >>>
| >>>       
| >>>> -----Original Message-----
| >>>> From: Georgios Karagiannis [mailto:[email-masked]]
| >>>> Sent: den 21 februari 2008 11:07
| >>>> To: [email-masked]; Ingemar Johansson S
| >>>> Cc: [email-masked]; [email-masked]; 
| >>>> [email-masked]; [email-masked]
| >>>> Subject: RE: [PCN] FW: RE: PCN encoding option
| >>>>
| >>>>
| >>>> Hi Phil, Hi all
| >>>>
| >>>> In order to make a selection of one single (or two) options, I 
| >>>> think that the PCN WG should get the possibility to 
| study all the 
| >>>> possible and PCN relevant encoding options.
| >>>>
| >>>> In my opinion the goal of the encoding draft is to provide this 
| >>>> information to the PCN-WG.
| >>>> Based on this information the PCN WG can discuss and 
| decide which 
| >>>> of the options should be used.
| >>>>
| >>>> The below text is copied from the current version of the 
| encoding 
| >>>> draft!
| >>>> Four options are described!
| >>>> Please note that the encoding draft should list all relevant 
| >>>> options with advantages and disadvantages.
| >>>>
| >>>> Phil and Ingemar, if you can add advantages, 
| disadvantages to the 
| >>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the 
| >>>> encoding draft, please do.
| >>>>
| >>>> Best regards,
| >>>> Georgios
| >>>>
| >>>>
| >>>>
| >>>> 3.2.  Encoding Using DSCP Field
| >>>>
| >>>>    In this type of encoding and transport method the
| >>>>         
| >> congestion and
| >>     
| >>>>    precongestion information is encoded into the 6 DSCP
| >>>>         
| >>> bits that are
| >>>       
| >>>>    transported in the IP header of the data packets.  
| >>>>         
| >> Four possible
| >>     
| >>>>    alternatives can be distinguished, as can be seen in
| >>>>         
| >>> Figure 3, with
| >>>       
| >>>>    details provided by 
| draft-westberg-pcn-load-control-02.txt [4].
| >>>>    Option 7 needs 2 additional DSCP values, Options 8 and 9
| >>>>         
| >>> need three
| >>>       
| >>>>    additional DSCP values and Option 10 needs four 
| additional DSCP
| >>>>    values.  Note that all additional and experimental DSCP
| >>>>         
| >>> values are
| >>>       
| >>>>    representing and are associated with the same PHB.  
| >>>>         
| >> The 1st, 2nd,
| >>     
| >>>>    3rd, and 4th DSCP values are representing DSCP values that are
| >>>>    assigned by IANA as DSCP experimental values, see RFC 
| 2211 [9].
| >>>>
| >>>>
| >>>>
| >>>>  
| >>>> --------------------------------------------------------------
| >>>> ---------
| >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 Add 
| >>>> |DSCP 4
| >>>> || 
| >>>> ===========++==========+===========+===========+===========+==
| >>>> =========|
| >>>> | Option 6  || Not-PCN  |    PCN    |   AM/TM   |    NA     | 
| >>>>    NA     |
| >>>> |-----------++----------+-----------+-----------+-----------+-
| >>>> ----------|
| >>>> | Option 7  || Not-PCN  |    PCN    |   AM/TM   |    AfM    | 
| >>>>    NA     |
| >>>> |-----------++----------+-----------+-----------+-----------+-
| >>>> ----------|
| >>>> | Option 8  || Not-PCN  |    PCN    |     AM    |    TM     | 
| >>>>    NA     |
| >>>> |-----------++----------+-----------+-----------+-----------+-
| >>>> ----------|
| >>>> | Option 9  || Not-PCN  |    PCN    |     AM    |    TM     | 
| >>>>    AfM    |
| >>>>  
| >>>> --------------------------------------------------------------
| >>>> ---------
| >>>>
| >>>>    Notes: Not-PCN means the packet is not PCN capable.
| >>>>
| >>>>           Figure 2: Encoding of PCN Information Using DSCP Field
| >>>>
| >>>> 3.2.1.  Benefits of Using DSCP Field
| >>>>
| >>>>    The main benefit of using the DSCP field is that it is not 
| >>>> affecting
| >>>>    the end-to-end ECN semantics and therefore the issues
| >>>>         
| >>> and concerns
| >>>       
| >>>>    raised in RFC 4774 [22] are not applicable for this encoding 
| >>>> scheme.
| >>>>    Another benefit is related to the fact that all 4 
| DSCP encoding
| >>>>    options depicted in Figure 2 can support the PCN capable not
| >>>>    congested (PCN) indication, the admission control 
| (AM) and flow
| >>>>    termination (TM) encoding states.  In addition Option 8
| >>>>         
| >>> and 10 can
| >>>       
| >>>>    support the ECMP solution.
| >>>>
| >>>> 3.2.2.  Drawbacks of Using DSCP Field
| >>>>
| >>>>    This type of encoding needs to use per PHB, in addition to the
| >>>>    original DSCP and depending on the encoding option used,
| >>>>         
| >>> one, two,
| >>>       
| >>>>    three, or four DSCP values, respectively.  These
| >>>>         
| >> additional DSCP
| >>     
| >>>>    values can be taken from the DSCP values that are not
| >>>>         
| >> defined by
| >>     
| >>>>    standards action, see RFC 2211 [9].  Note that all the
| >>>>         
| >> additional
| >>     
| >>>>    DSCP values are representing and are associated with one
| >>>>         
| >>> PHB.  The
| >>>       
| >>>>    value of this DSCP/PHB can either follow a standards 
| action or 
| >>>> use a
| >>>>    value that is applied for experimental or local use.  It is 
| >>>> important
| >>>>    to note that the number of the DSCP values used for local or
| >>>>    experimental use is restricted and therefore the number of 
| >>>> different
| >>>>    PHBs supported in the PCN domain will also be restricted. 
| >>>>
| >>>> Best regards,
| >>>> Georgios
| >>>>
| >>>>
| >>>>         
| >>>>> -----Original Message-----
| >>>>> From: [email-masked] [mailto:[email-masked]] On
| >>>>>           
| >>>> Behalf Of
| >>>>         
| >>>>> [email-masked]
| >>>>> Sent: donderdag 21 februari 2008 10:24
| >>>>> To: [email-masked]; 
| >>>>> [email-masked]; [email-masked]
| >>>>> Cc: [email-masked]; [email-masked]
| >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option
| >>>>>
| >>>>> Ingemar
| >>>>>
| >>>>> Re
| >>>>>
| >>>>>           
| >>>>>> consider the end to end ECN usecases
| >>>>>>             
| >>>>> I believe that the emails below about Toby's encoding
| >>>>>           
| >> proposal do
| >>     
| >>>>> indeed already consider ECN. Would appreciate it if you
| >>>>>           
| >> could add
| >>     
| >>>>> further text to it to better capture the (pros and) cons.
| >>>>>
| >>>>>           
| >>>>>> more DSCP codepoints
| >>>>>>             
| >>>>> I think you may be proposing an encoding that uses all dscp
| >>>>>           
| >>>> codepoints
| >>>>         
| >>>>> (as has Georgios). That's fine - but a "1 pager"
| >>>>> setting out this option with its pros and cons (ie
| >>>>>           
| >>> similar to what
| >>>       
| >>>>> toby has done below) is needed I think! At the moment we
| >>>>>           
| >>>> have lots of
| >>>>         
| >>>>> options on the table - in order to reach a decision, I
| >>>>>           
| >>>> think we really
| >>>>         
| >>>>> need very few options but with their pros and cons better
| >>>>>           
| >>> laid out.
| >>>       
| >>>>> I haven't managed to get to your draft yet, sorry (next week
| >>>>> hopefully)
| >>>>> -
| >>>>> Thanks
| >>>>> Phil
| >>>>>
| >>>>>
| >>>>>           
| >>>>>> -----Original Message-----
| >>>>>> From: Ingemar Johansson S
| >>>>>>             
| >>>> [mailto:[email-masked]]
| >>>>         
| >>>>>> Sent: 21 February 2008 06:43
| >>>>>> To: Eardley,PL,Philip,CXR9 R;
| >>>>>>             
| >> [email-masked];
| >>     
| >>>>>> Moncaster,T,Toby,CXR9 R
| >>>>>> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R
| >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option
| >>>>>>
| >>>>>> Hi
| >>>>>>
| >>>>>> In this discussion it may be well worth the effort to
| >>>>>>             
| >>>>> consider the end
| >>>>>           
| >>>>>> to end ECN usecases that we foresee when considering
| >>>>>>             
| >>> various PCN
| >>>       
| >>>>>> encoding options.
| >>>>>> Please have a look at
| >>>>>>
| >>>>>>             
| >> 
| http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt
| >>     
| >>>>>> for a discussion of the use cases and a motivation to why
| >>>>>>             
| >>>> end to end
| >>>>         
| >>>>> ECN
| >>>>>           
| >>>>>> should be maintained even across PCN nodes even for non
| >>>>>>             
| >>>> DF traffic.
| >>>>         
| >>>>>> That said I realize that there is some cost associated to
| >>>>>>             
| >>>>> the use of
| >>>>>           
| >>>>>> DSCP codepoints, this cost must however be weighted against
| >>>>>>             
| >>>>> the risk
| >>>>>           
| >>>>>> that other functionality like end to end ECN semantics is
| >>>>>>             
| >>>> probably
| >>>>         
| >>>>>> broken if a PCN encoding option "fiddles" with the ECN
| >>>>>>             
| >>> bits. It is
| >>>       
| >>>>> easy
| >>>>>           
| >>>>>> to see that if one wish to maintain support for end to
| >>>>>>             
| >>>> end ECN (not
| >>>>         
| >>>>> only
| >>>>>           
| >>>>>> in DF class) it simply costs more DSCP codepoints.
| >>>>>> I am not explicitly saying don't do this or that but I wish
| >>>>>>             
| >>>>> to avoid a
| >>>>>           
| >>>>>> situation where one technique has to be avoided in favor of
| >>>>>>             
| >>>>> the other
| >>>>> as
| >>>>>           
| >>>>>> it may in the end prevent deployment of both. If one can
| >>>>>>             
| >>>>> yank the two
| >>>>>           
| >>>>>> together so much the better even though the cost e.g in
| >>>>>>             
| >>> DSCP code
| >>>       
| >>>>> points
| >>>>>           
| >>>>>> is regarded as higher.
| >>>>>>
| >>>>>> Regards
| >>>>>> Ingemar
| >>>>>>
| >>>>>>             
| >>>>>>> -----Original Message-----
| >>>>>>> From: [email-masked] [mailto:[email-masked]]
| >>>>>>>               
| >>>>> On Behalf
| >>>>>           
| >>>>>>> Of [email-masked]
| >>>>>>> Sent: den 20 februari 2008 17:44
| >>>>>>> To: [email-masked]; [email-masked]
| >>>>>>> Cc: [email-masked]; [email-masked]
| >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option
| >>>>>>>
| >>>>>>> Thanks Michael
| >>>>>>>
| >>>>>>> I agree with you that spending one DSCP value is quite
| >>>>>>>               
| >>>> expensive
| >>>>         
| >>>>>>> (not two, as one is spent anyway). I think the only way
| >>>>>>>               
| >>>> of really
| >>>>         
| >>>>>>> assessing this properly is for an alternative proposal
| >>>>>>>               
| >>>> (with pros
| >>>>         
| >>>>>>> and cons) that requires only one DSCP.
| >>>>>>> Then we can see where the consensus for the best
| >>>>>>>               
| >> (/least bad)
| >>     
| >>>>>>> encoding lies. Personally I have no axe to grind for
| >>>>>>>               
| >>> or against
| >>>       
| >>>>>>> either - I'm not yet convinced that the proposal below is
| >>>>>>>               
| >>>>> definitely
| >>>>>           
| >>>>>>> the way to go, until compared it in detail with other
| >>>>>>>               
| >>> proposals.
| >>>       
| >>>>>>> So I think it would be really useful to have a "1
| >>>>>>>               
| >> pager" for
| >>     
| >>>>>>> alternative
| >>>>>>> proposal(s) before the ietf, as I think this would make
| >>>>>>>               
| >>>>> Philadelphia
| >>>>>           
| >>>>>>> discussions more productive.
| >>>>>>>
| >>>>>>>
| >>>>>>> You're correct about one of the motivations
| >>>>>>>               
| >>>> (advantages) for this
| >>>>         
| >>>>>>> proposal (although I don't think the issues are exactly
| >>>>>>>               
| >>>>> the same for
| >>>>>           
| >>>>>>> 11 leakage as 01/10 leakage).
| >>>>>>>
| >>>>>>> Consider the case where 11 leaks out of the PCN
| >>>>>>>               
| >>> domain. If the
| >>>       
| >>>>>>> endpoints are ECN capable, then the ECN source slows
| >>>>>>>               
| >>>> down (seems
| >>>>         
| >>>>>>> reasonable). If they're not capable, then the impact
| >>>>>>>               
| >>>> outside the
| >>>>         
| >>>>>>> domain isn't any different to what would happen without
| >>>>>>>               
| >>>>> PCN-domain.
| >>>>>           
| >>>>>>> Consider the case where ECN-11 leaks into the PCN domain.
| >>>>>>> Then this will lead to either flow admission or
| >>>>>>>               
| >>>>> termination in the
| >>>>>           
| >>>>>>> PCN-domain. These are both safe, in that the reaction is
| >>>>>>>               
| >>>>> (I believe)
| >>>>>           
| >>>>>>> at least as severe as would happen in an all ECN world.
| >>>>>>> You mention that this might not terminate the ECN-11 flow 
| >>>>>>> specifically (some other flow might get terminated instead).
| >>>>>>> I think this is true, though it also implies that [1]
| >>>>>>>               
| >>>>> end-to-end ECN
| >>>>>           
| >>>>>>> & PCN on the same flow really is useful, [2] the
| >>>>>>>               
| >> mechanism (eg
| >>     
| >>>>>>> tunnelling) to carry ECN-marking transparently across the
| >>>>>>>               
| >>>>> PCN-domain
| >>>>>           
| >>>>>>> has also failed, [3] the flows which are terminated
| >>>>>>>               
| >>> aren't other
| >>>       
| >>>>>>> ECN-11 flows that are also getting in due to the same 
| >>>>>>> misconfiguration.
| >>>>>>>
| >>>>>>> Best wishes
| >>>>>>> Phil
| >>>>>>>               
| >>>>>>>> -----Original Message-----
| >>>>>>>> From: Michael Menth
| >>>>>>>>                 
| >>> [mailto:[email-masked]]
| >>>       
| >>>>>>>> Sent: 20 February 2008 10:50
| >>>>>>>> To: Moncaster,T,Toby,CXR9 R
| >>>>>>>> Cc: [email-masked]; Eardley,PL,Philip,CXR9 R;
| >>>>>>>>                 
| >>>> [email-masked];
| >>>>         
| >>>>>>>> [email-masked]; [email-masked];
| >>>>>>>>                 
| >>>> [email-masked];
| >>>>         
| >>>>>>>> [email-masked]; Briscoe,RJ,Bob,CXR9 R
| >>>>>>>> Subject: Re: FW: RE: PCN encoding option
| >>>>>>>>
| >>>>>>>> Hi Toby,
| >>>>>>>>
| >>>>>>>> as I understand the proposal, the motivation is to
| >>>>>>>>                 
| >>>> avoid 01/10
| >>>>         
| >>>>>>>> codepoints as it is not good if they leak out of the
| >>>>>>>>                 
| >>>>> network since
| >>>>>           
| >>>>>>> 01/10
| >>>>>>>               
| >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes.
| >>>>>>>>                 
| >>>>>>> However, there is
| >>>>>>>               
| >>>>>>>> the same problem with 11 marking, i.e. 11-packets
| >>>>>>>>                 
| >> may not be
| >>     
| >>>>> dropped
| >>>>>           
| >>>>>>> by
| >>>>>>>               
| >>>>>>>> ECN nodes outside the PCN domain although endpoints
| >>>>>>>>                 
| >>>> are not ECN
| >>>>         
| >>>>>>> capable.
| >>>>>>>               
| >>>>>>>> Even if 11-packets trigger flow termination, it is not
| >>>>>>>>                 
| >>>>>>> guaranteed that
| >>>>>>>               
| >>>>>>>> exactly the marked flow going over an overloaded
| >>>>>>>>                 
| >> ECN node is
| >>     
| >>>>>>> terminated.
| >>>>>>>               
| >>>>>>>> Just want to say that this solution wants to solve a
| >>>>>>>>                 
| >>>>> problem that
| >>>>>           
| >>>>>>> exists
| >>>>>>>               
| >>>>>>>> only in case of misconfiguration (leaking packets), but
| >>>>>>>>                 
| >>>>>>> does not fully
| >>>>>>>               
| >>>>>>>> achieve that objective. Therefore, I feel that
| >>>>>>>>                 
| >>>> spending two DSCP
| >>>>         
| >>>>>>> values
| >>>>>>>               
| >>>>>>>> is quite expensive.
| >>>>>>>>
| >>>>>>>> Regards,
| >>>>>>>>
| >>>>>>>>     Michael
| >>>>>>>>
| >>>>>>>> [email-masked] wrote:
| >>>>>>>>                 
| >>>>>>>>> All,
| >>>>>>>>>
| >>>>>>>>> Phil and I have just been discussing the encoding draft
| >>>>>>>>>                   
| >>>>>>> and feel we
| >>>>>>> may
| >>>>>>>               
| >>>>>>>>> have lit upon a neat solution that seems to have
| >>>>>>>>>                   
| >>>> lots of pros
| >>>>         
| >>>>> and
| >>>>>           
| >>>>>>> few
| >>>>>>>               
| >>>>>>>>> cons... In order to get a better feeling for this
| >>>>>>>>>                   
| >>>>>>> proposal I will go
| >>>>>>>               
| >>>>>>>>> through the simplified version without Affected
| >>>>>>>>>                   
| >>>> marking first:
| >>>>         
| >>>>>>>>> PCN Meaning		ECN 	 DSCP
| >>>>>>>>>
| >>>>>>>>> PCN capable		00	 PCN 1
| >>>>>>>>> Admission Mark	11	 PCN 1
| >>>>>>>>> Termination Mark	11/00	 PCN 2
| >>>>>>>>>
| >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with
| >>>>>>>>>                   
| >>> the same PCN
| >>>       
| >>>>>>> behaviour
| >>>>>>>               
| >>>>>>>>> aggregate.
| >>>>>>>>>
| >>>>>>>>> Pros:
| >>>>>>>>>  o  Termination marking and admission marking are
| >>>>>>>>>                   
| >>>> independent,
| >>>>         
| >>>>> eg
| >>>>>           
| >>>>>>>>> termination marking can be done after a packet has been
| >>>>>>>>>                   
| >>>>> admission
| >>>>>           
| >>>>>>>>> marked. Therefore a router can write AM or TM without
| >>>>>>>>>                   
| >>>>>>> having to read
| >>>>>>> the
| >>>>>>>               
| >>>>>>>>> packet's PCN marking first, which is easier to
| >>>>>>>>>                   
| >>>>> implement. (Note:
| >>>>>           
| >>>>>>>>> Over-writing a TM with AM is not allowed for
| >>>>>>>>>                   
| >> 3SM & CL, see
| >>     
| >>>>>>>>> draft-charny-pcn-comparison.)
| >>>>>>>>>
| >>>>>>>>> o  This scheme avoids giving semantics to ECT(0) and
| >>>>>>>>>                   
| >>>>>>> ECT(1). This is
| >>>>>>>               
| >>>>>>>>> safest option if packets leak outside the PCN
| >>>>>>>>>                   
| >>> region, due to
| >>>       
| >>>>> some
| >>>>>           
| >>>>>>> fort
| >>>>>>>               
| >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant
| >>>>>>>>>                   
| >>>>>>> for a single
| >>>>>>>               
| >>>>>>>>> domain deployment of PCN).
| >>>>>>>>>
| >>>>>>>>> o  It leaves open the possibility of using ECT(0) and
| >>>>>>>>>                   
| >>>>>>> ECT(1) in some
| >>>>>>>               
| >>>>>>>>> mysterious way in a future end-to-end PCN deployment
| >>>>>>>>>
| >>>>>>>>> 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.
| >>>>>           
| >>>>>>>>> o  Incremental deployment steps are possible [1]
| >>>>>>>>>                   
| >>>>> could deploy SM
| >>>>>           
| >>>>>>>>> initially and later AM/TM. Just add the second
| >>>>>>>>>                   
| >>>>>>> DSCP.
| >>>>>>>               
| >>>>>>>>> If a router isn't upgraded at the same time nothing
| >>>>>>>>>                   
| >>>>> too horrific
| >>>>>           
| >>>>>>>>> happens.
| >>>>>>>>> [2] could just deploy admission control & add
| >>>>>>>>>                   
| >>>>> termination later,
| >>>>>           
| >>>>>>> just by
| >>>>>>>               
| >>>>>>>>> adding a new DSCP; there is no need to change the
| >>>>>>>>>                   
| >>>>>>> encoding and check
| >>>>>>> for
| >>>>>>>               
| >>>>>>>>> backwards compatibility? Vice-versa is also ok?
| >>>>>>>>>
| >>>>>>>>> Cons:
| >>>>>>>>> o  It needs an extra DSCP, per PCN behaviour aggregate.
| >>>>>>>>>                   
| >>>>> (Although
| >>>>>           
| >>>>>>>>> possibly it's OK to use the same DSCP for TM for
| >>>>>>>>>                   
| >>>> all PCN BAs?)
| >>>>         
| >>>>>>>>> o  If a packet (in a PCN flow) arrives at the
| >>>>>>>>>                   
| >> egress with
| >>     
| >>>>>>> its ECN =
| >>>>>>> 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)
| >>>>>>>               
| >>>>>>>>> o  If the PCN-domain is operating multipath routing
| >>>>>>>>>                   
| >>>>>>> (ECMP) that uses
| >>>>>>> the
| >>>>>>>               
| >>>>>>>>> DSCP to select routes, then there may be mis-ordering
| >>>>>>>>>                   
| >>>>> of packets
| >>>>>           
| >>>>>>> within
| >>>>>>>               
| >>>>>>>>> a flow. This may be OK as (1) no-one has yet said
| >>>>>>>>>                   
| >>>> they know of
| >>>>         
| >>>>> an
| >>>>>           
| >>>>>>> ECMP
| >>>>>>>               
| >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of
| >>>>>>>>>                   
| >>>>>>> mis-ordering
| >>>>>>> when
| >>>>>>>               
| >>>>>>>>> there is termination marking may be acceptable
| >>>>>>>>>
| >>>>>>>>> If Affected marking is needed then the scheme can be
| >>>>>>>>>                   
| >>>>> modified as
| >>>>>           
| >>>>>>>>> follows:
| >>>>>>>>>
| >>>>>>>>> PCN Meaning		ECN 	DSCP
| >>>>>>>>>
| >>>>>>>>> PCN capable		00	PCN 1
| >>>>>>>>> Admission Mark	11	PCN 1
| >>>>>>>>> Termination Mark	11	PCN 2
| >>>>>>>>> Affected Mark	00	PCN 2
| >>>>>>>>>
| >>>>>>>>> The pros for this scheme are broadly similar to
| >>>>>>>>>                   
| >> the above.
| >>     
| >>>>> However
| >>>>>           
| >>>>>>> there
| >>>>>>>               
| >>>>>>>>> is a new con which may or may not matter: If a packet is
| >>>>>>>>>                   
| >>>>> affected
| >>>>>           
| >>>>>>> marked
| >>>>>>>               
| >>>>>>>>> and a later node is doing admission marking then it will
| >>>>>>>>>                   
| >>>>>>> reset the
| >>>>>>>               
| >>>>>>>>> affected mark to a termination mark. Work would
| >>>>>>>>>                   
| >> be needed
| >>     
| >>>>>>> to see if
| >>>>>>> this
| >>>>>>>               
| >>>>>>>>> skews the results and causes significant
| >>>>>>>>>                   
| >>> over-termination or
| >>>       
| >>>>> not.
| >>>>>           
| >>>>>>>>> Please could people look through this scheme and
| >>>>>>>>>                   
| >>>>> highlight any
| >>>>>           
| >>>>>>>>> additional concerns that they may have (and extra
| >>>>>>>>>                   
| >>>>> benefits too).
| >>>>> I
| >>>>>           
| >>>>>>> would
| >>>>>>>               
| >>>>>>>>> like to get as many opinions as possible.
| >>>>>>>>>
| >>>>>>>>> What I want to avoid is people just emailing back with
| >>>>>>>>>                   
| >>>>>>> "why not try
| >>>>>>> this
| >>>>>>>               
| >>>>>>>>> scheme instead". Currently we seem to have a plethora of
| >>>>>>>>>                   
| >>>>> possible
| >>>>>           
| >>>>>>>>> schemes on the table and people need to start putting
| >>>>>>>>>                   
| >>>>> down much
| >>>>>           
| >>>>>>> clearer
| >>>>>>>               
| >>>>>>>>> pros and cons for the schemes they support... 
| >>>>>>>>>                   
| >> So it could
| >>     
| >>>>>>> be good to
| >>>>>>>               
| >>>>>>>>> have a similar "one page" email about a specific
| >>>>>>>>>                   
| >>> scheme that
| >>>       
| >>>>> only
| >>>>>           
| >>>>>>> uses
| >>>>>>>               
| >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead.
| >>>>>>>>>
| >>>>>>>>> Toby
| >>>>>>>>>
| >>>>>>>>>                   
| >>> 
| ____________________________________________________________________
| >>>       
| >>>>>>>>> Toby Moncaster, <[email-masked]>
| >>>>>>>>>                   
| >> Networks Research
| >>     
| >>>>>>> Centre, BT
| >>>>>>>               
| >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44
| >>>>>>>>>                   
| >>> 1473 648734
| >>>       
| >>>>>>>> --
| >>>>>>>> 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
| >>>>>>>>                 
| >>>>>>> _______________________________________________
| >>>>>>> PCN mailing list
| >>>>>>> [email-masked]
| >>>>>>> http://www.ietf.org/mailman/listinfo/pcn
| >>>>>>>
| >>>>>>>               
| >>>>> _______________________________________________
| >>>>> PCN mailing list
| >>>>> [email-masked]
| >>>>> http://www.ietf.org/mailman/listinfo/pcn
| >>>>>
| >>>>>           
| >>>>
| >>>>         
| 
| --
| 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
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| http://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 22 Feb 2008 10:46:47 +0100

Hi

See inline

/Ingemar

> Sent: den 22 februari 2008 10:13
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> this solution essentially spends a DSCP to save 11-marking 
> through the PCN domain and allow them to be PCN-marked. This 
> is a rather high price, in particular because the PCN packets 
> need to be remarked to 00. This has the consequence that ECN 
> capability is lost for the rest of the path.
Not sure that I agree, yes the ECT(0), ECT(1) codepoints are lost and
there goes also the ECN nonce and the "inband" ECN capability signaling.
A router outside the PCN domain wont be able to set ECN-CE. However if
the ECN capability is negotiated out of band for the wireless endpoints
and the up and downlink wireless nodes, these will be ECN-CE capable but
without the nonce capability. 
 
> 2) let them go through the PCN domain, take them into account 
> for metering, but do not remark them.
> The first option loses ECN capability for PCN traffic, the 
> second option keeps it on the subpath before entering the PCN domain.
Not sure I follow here. What would option 2 look like?
My interpretation: Packets with DSCP=EF enters the PCN domain, at
ingress they are remarked as DSCP=PCN unless ECN="11", in which case
DSCP=EF. What about ECN="01" or "01" will these also be kept as DSCP=EF
or will the ECN bits be set to "00".
Please explain.

> >> what are the real options people support for the encoding and why 
> >> they support them...
> >>
> >> Just one quick observation - if we have to leave 11 
> unchanged across 
> >> the PCN domain this will mean that such packets can't be 
> PCN marked 
> >> and thus they should not form part of any PCN aggregate (in my 
> >> opinion)...
> >>     
> >
> > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN 
> egress PCN 
> > 2 is mapped back to the ECN bits as ECN-CE "11".
> >
> > disregards the leakage issue, also it possible that this 
> alternative 
> > or something similar is given in the PCN encoding draft but I don't 
> > think so as this alternative does not preserve the end to end ECN 
> > semantics to 100%, rather it assumes that negotiation of the use of 
> > ECN is done out of band at session setup.
> >
> > /Ingemar
> >
> >  
> >   
> >> Toby
> >>
> >>     
> >>> One would then end up with a PCN encoding schema like (I beleve 
> >>> option 5 in figure 1 in the PCN encoding draft) is the closest.
> >>>
> >>> PCN Meaning		ECN 	 DSCP
> >>> enter the first PCN domain, after exit from the PCN 
> domain routers 
> >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3).
> >>> Wireless nodes
> >>> today if it will be a best effort traffic alternatiive or 
> if there 
> >>> is a benefit with it even with QoS and DCCP can use ECN nonce.
> >>>
> >>> /Ingemar
> >>>
> >>>
> >>>       
> >>>> In order to make a selection of one single (or two) options, I 
> >>>> think that the PCN WG should get the possibility to 
> study all the 
> >>>> possible and PCN relevant encoding options.
> >>>>
> >>>> Based on this information the PCN WG can discuss and 
> decide which 
> >>>> of the options should be used.
> >>>>
> >>>> The below text is copied from the current version of the 
> encoding 
> >>>> draft!
> >>>> ones already mentioned below in Section 3.2.1 and 3.2.2 of the 
> >>>> encoding draft, please do.
> >>>>
> >>>> Best regards,
> >>>> Georgios
> >>>>
> >>>>
> >>>>
> >>>>    details provided by 
> draft-westberg-pcn-load-control-02.txt [4].
> >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 Add 
> >>>> |DSCP 4
> >>>> || 
> action or 
> >>>> use a
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: <[email-masked]>
Date: Fri, 22 Feb 2008 10:16:46 -0000

Surely option 2 also opens up a bit of a DoS issue doesn't it? What
happens if a malicious router or sender chooses to inject spurious CE
marks? Won't this completely distort all the PCN metering? Also there is
the added issue of not knowing how frequently a wireless router might be
sending CE marks anyway. These are in addition to the problems being
expressed below by Ingemar.

Overall I still favour some approach of tunnelling the ECN mark (which
Ingemar's revised solution sort of did). There still remains an issue
with the discarding of ECT(0) and ECT(1) which brings it in conflict
with RFC4774.

Toby

> Sent: 22 February 2008 09:47
> To: [email-masked]
> Cc: Moncaster,T,Toby,CXR9 R; [email-masked]; 
> Eardley,PL,Philip,CXR9 R; [email-masked]; Briscoe,RJ,Bob,CXR9 R
> > >>>>    raised in RFC 4774 [22] are not applicable for this 
> encoding 
> > >>>> scheme.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 22 Feb 2008 11:50:08 +0100

Toby,

you are right, there's a control issue with ECN once we talk about PCN 
to steer the behviour of network elements in the case of (pre) congestion. 
I'm not sure, wether PCN is supposed to work on that, but I also can't 
tell who is. If there's a fancy application eligible for PCN QoS transport 
sending ECN CE marks constantly or as you mention spurious, while 
absolutely not caring about ECN's original purpose, may it have an 
advantage then?

Is it a requirement to reset ECN CE from 11 to 01/10 or even 00 at 
the User Network Interface?

The bad provider (you've mentioned a server as executing an attack) 
is another topic.

Maybe discard of 11 packets at the PCN ingress node, should their 
number not reduce a while after a (pre) congestion indication would
be an option.

Michael made a fair proposal for "good" users, and I support his 
idea. But we need to protect our mechanisms against malicious users 
too, that's correct.

Regards,

Ruediger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] 
| Sent: Friday, February 22, 2008 11:17 AM
| To: [email-masked]; 
| [email-masked]
| Cc: [email-masked]; [email-masked]
| Subject: Re: [PCN] FW: RE: PCN encoding option
| 
| Surely option 2 also opens up a bit of a DoS issue doesn't 
| it? What happens if a malicious router or sender chooses to 
| inject spurious CE marks? Won't this completely distort all 
| the PCN metering? Also there is the added issue of not 
| knowing how frequently a wireless router might be sending CE 
| marks anyway. These are in addition to the problems being 
| expressed below by Ingemar.
| 
| Overall I still favour some approach of tunnelling the ECN 
| mark (which Ingemar's revised solution sort of did). There 
| still remains an issue with the discarding of ECT(0) and 
| ECT(1) which brings it in conflict with RFC4774.
| 
| Toby
| 
| > -----Original Message-----
| > From: Ingemar Johansson S [mailto:[email-masked]]
| > Sent: 22 February 2008 09:47
| > To: [email-masked]
| > Cc: Moncaster,T,Toby,CXR9 R; [email-masked];
| > Eardley,PL,Philip,CXR9 R; [email-masked]; Briscoe,RJ,Bob,CXR9 R
| > Subject: RE: [PCN] FW: RE: PCN encoding option
| > 
| > Hi
| > 
| > See inline
| > 
| > /Ingemar
| > 
| > > -----Original Message-----
| > > From: Michael Menth [mailto:[email-masked]]
| > > Sent: den 22 februari 2008 10:13
| > > To: Ingemar Johansson S
| > > Cc: [email-masked]; [email-masked]; 
| > > [email-masked]; [email-masked]; [email-masked]
| > > Subject: Re: [PCN] FW: RE: PCN encoding option
| > > 
| > > Hi Ingemar,
| > > 
| > > this solution essentially spends a DSCP to save 
| 11-marking through 
| > > the PCN domain and allow them to be PCN-marked. This is a rather 
| > > high price, in particular because the PCN packets need to be 
| > > remarked to 00. This has the consequence that ECN 
| capability is lost 
| > > for the rest of the path.
| > Not sure that I agree, yes the ECT(0), ECT(1) codepoints 
| are lost and 
| > there goes also the ECN nonce and the "inband" ECN capability 
| > signaling.
| > A router outside the PCN domain wont be able to set ECN-CE. 
| However if 
| > the ECN capability is negotiated out of band for the wireless 
| > endpoints and the up and downlink wireless nodes, these 
| will be ECN-CE 
| > capable but without the nonce capability.
| >  
| > > Therefore, I opt for one of the two versions
| > > 1) discard 11-marked PCN packets before entering the PCN domain OR
| > > 2) let them go through the PCN domain, take them into account for 
| > > metering, but do not remark them.
| > > The first option loses ECN capability for PCN traffic, the second 
| > > option keeps it on the subpath before entering the
| > PCN domain.
| > Not sure I follow here. What would option 2 look like?
| > My interpretation: Packets with DSCP=EF enters the PCN domain, at 
| > ingress they are remarked as DSCP=PCN unless ECN="11", in 
| which case 
| > DSCP=EF. What about ECN="01" or "01" will these also be kept as 
| > DSCP=EF or will the ECN bits be set to "00".
| > Please explain.
| > 
| > 
| > 
| > > 
| > > Regards,
| > > 
| > >     Michael
| > > 
| > > Ingemar Johansson S wrote:
| > > > Hi
| > > >
| > > > Answers inline
| > > >
| > > >   
| > > >> -----Original Message-----
| > > >> From: [email-masked] [mailto:[email-masked]]
| > > >> Sent: den 21 februari 2008 15:34
| > > >> To: Ingemar Johansson S; [email-masked]; 
| > > >> [email-masked]
| > > >> Cc: [email-masked]; [email-masked]; 
| > > >> [email-masked]
| > > >> Subject: RE: [PCN] FW: RE: PCN encoding option
| > > >>
| > > >> Hi Ingemar,
| > > >>
| > > >> This is exactly the sort of thing Phil and I were hoping
| > > to trigger
| > > >> people to write in response to our email. We are hoping to
| > > settle on
| > > >> what are the real options people support for the
| > encoding and why
| > > >> they support them...
| > > >>
| > > >> Just one quick observation - if we have to leave 11
| > > unchanged across
| > > >> the PCN domain this will mean that such packets can't be
| > > PCN marked
| > > >> and thus they should not form part of any PCN aggregate (in my 
| > > >> opinion)...
| > > >>     
| > > >
| > > > Realized that this is one (big) problem, thanks for
| > > pointing out this
| > > > issue.
| > > >
| > > > The next alternative is then
| > > > PCN Meaning		 ECN 	 DSCP
| > > > =============================
| > > > PCN capable		 00    PCN 1
| > > > Admission Mark	 01	 PCN 1
| > > > Termination Mark	 10	 PCN 1
| > > >
| > > > PCN capable+ECN CE 00    PCN 2
| > > > AM+ECN CE     	 01	 PCN 2
| > > > TM+ECN CE     	 10	 PCN 2
| > > >
| > > > I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN
| > > egress PCN
| > > > 2 is mapped back to the ECN bits as ECN-CE "11".
| > > >
| > > > AfM can also be included in the schema
| > > >
| > > > I know this does cost an extra DSCP codepoint and it completely 
| > > > disregards the leakage issue, also it possible that this
| > > alternative
| > > > or something similar is given in the PCN encoding draft
| > but I don't
| > > > think so as this alternative does not preserve the end 
| to end ECN 
| > > > semantics to 100%, rather it assumes that negotiation of
| > the use of
| > > > ECN is done out of band at session setup.
| > > >
| > > > /Ingemar
| > > >
| > > >  
| > > >   
| > > >> Toby
| > > >>
| > > >>     
| > > >>> -----Original Message-----
| > > >>> From: Ingemar Johansson S
| > > [mailto:[email-masked]]
| > > >>> Sent: 21 February 2008 13:47
| > > >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R
| > > >>> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R; 
| > > >>> [email-masked]; Moncaster,T,Toby,CXR9 R
| > > >>> Subject: RE: [PCN] FW: RE: PCN encoding option
| > > >>>
| > > >>> Hi
| > > >>>
| > > >>> Putting the issues with "leakage" aside (I cannot tell
| > > how serious
| > > >>> this problem really is).
| > > >>>
| > > >>> I would prefer to sacrifice the end to end ECN 
| semantics for the
| > > >>> ECT(0) and ECT(1) codepoints instead of the ECN-CE
| > codepoint. The
| > > >>> reason is simply that from a realtime communication
| > > >>>       
| > > >> scenario with out
| > > >>     
| > > >>> of band signaling it is always possible to negotiate the
| > > >>>       
| > > >> use of ECN CE
| > > >>     
| > > >>> mark in wireless nodes by means of eg. SIP signaling. 
| > > Also, atleast
| > > >>> for RTP/UDP I see little use for ECN nonce like it is done
| > > >>>       
| > > >> with TCP as
| > > >>     
| > > >>> this is more or less an anti-cheat feature.
| > > >>>  
| > > >>>
| > > >>> One would then end up with a PCN encoding schema like 
| (I beleve 
| > > >>> option 5 in figure 1 in the PCN encoding draft) is 
| the closest.
| > > >>>
| > > >>> PCN Meaning		ECN 	 DSCP
| > > >>> =============================
| > > >>> PCN capable		00	 PCN 1
| > > >>> Admission Mark	01	 PCN 1
| > > >>> Termination Mark	10	 PCN 1
| > > >>>
| > > >>> At PCN ingress the ECT(0) and ECT(1) codepoints should be
| > > >>>       
| > > >> set to "00",
| > > >>     
| > > >>> likewise at PCN egress. ECN CE is however left untouched. 
| > > >>>       
| > > >> This has the
| > > >>     
| > > >>> effect that routers will be able to set ECN-CE on packets
| > > >>>       
| > > >> before they
| > > >>     
| > > >>> enter the first PCN domain, after exit from the PCN
| > > domain routers
| > > >>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3).
| > > >>> Wireless nodes
| > > >>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can
| > > >>>       
| > > >> however set
| > > >>     
| > > >>> ECN CE as this is can be managed by out of band signaling.
| > > >>>
| > > >>> Besides this I would prefer a solution that maintains
| > end to end
| > > >>> semantics regardless of DSCP value. If one consider DCCP we
| > > >>>       
| > > >> don't know
| > > >>     
| > > >>> today if it will be a best effort traffic alternatiive or
| > > if there
| > > >>> is a benefit with it even with QoS and DCCP can use ECN nonce.
| > > >>>
| > > >>> /Ingemar
| > > >>>
| > > >>>
| > > >>>       
| > > >>>> -----Original Message-----
| > > >>>> From: Georgios Karagiannis [mailto:[email-masked]]
| > > >>>> Sent: den 21 februari 2008 11:07
| > > >>>> To: [email-masked]; Ingemar Johansson S
| > > >>>> Cc: [email-masked]; [email-masked]; 
| > > >>>> [email-masked]; [email-masked]
| > > >>>> Subject: RE: [PCN] FW: RE: PCN encoding option
| > > >>>>
| > > >>>>
| > > >>>> Hi Phil, Hi all
| > > >>>>
| > > >>>> In order to make a selection of one single (or two) 
| options, I 
| > > >>>> think that the PCN WG should get the possibility to
| > > study all the
| > > >>>> possible and PCN relevant encoding options.
| > > >>>>
| > > >>>> In my opinion the goal of the encoding draft is to
| > provide this
| > > >>>> information to the PCN-WG.
| > > >>>> Based on this information the PCN WG can discuss and
| > > decide which
| > > >>>> of the options should be used.
| > > >>>>
| > > >>>> The below text is copied from the current version of the
| > > encoding
| > > >>>> draft!
| > > >>>> Four options are described!
| > > >>>> Please note that the encoding draft should list all relevant 
| > > >>>> options with advantages and disadvantages.
| > > >>>>
| > > >>>> Phil and Ingemar, if you can add advantages,
| > > disadvantages to the
| > > >>>> ones already mentioned below in Section 3.2.1 and 
| 3.2.2 of the 
| > > >>>> encoding draft, please do.
| > > >>>>
| > > >>>> Best regards,
| > > >>>> Georgios
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>> 3.2.  Encoding Using DSCP Field
| > > >>>>
| > > >>>>    In this type of encoding and transport method the
| > > >>>>         
| > > >> congestion and
| > > >>     
| > > >>>>    precongestion information is encoded into the 6 DSCP
| > > >>>>         
| > > >>> bits that are
| > > >>>       
| > > >>>>    transported in the IP header of the data packets.  
| > > >>>>         
| > > >> Four possible
| > > >>     
| > > >>>>    alternatives can be distinguished, as can be seen in
| > > >>>>         
| > > >>> Figure 3, with
| > > >>>       
| > > >>>>    details provided by
| > > draft-westberg-pcn-load-control-02.txt [4].
| > > >>>>    Option 7 needs 2 additional DSCP values, Options 8 and 9
| > > >>>>         
| > > >>> need three
| > > >>>       
| > > >>>>    additional DSCP values and Option 10 needs four
| > > additional DSCP
| > > >>>>    values.  Note that all additional and experimental DSCP
| > > >>>>         
| > > >>> values are
| > > >>>       
| > > >>>>    representing and are associated with the same PHB.  
| > > >>>>         
| > > >> The 1st, 2nd,
| > > >>     
| > > >>>>    3rd, and 4th DSCP values are representing DSCP
| > values that are
| > > >>>>    assigned by IANA as DSCP experimental values, see RFC
| > > 2211 [9].
| > > >>>>
| > > >>>>
| > > >>>>
| > > >>>>  
| > > >>>> 
| --------------------------------------------------------------
| > > >>>> ---------
| > > >>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add
| > DSCP 3 Add
| > > >>>> |DSCP 4
| > > >>>> || 
| > > >>>> 
| ===========++==========+===========+===========+===========+==
| > > >>>> =========|
| > > >>>> | Option 6  || Not-PCN  |    PCN    |   AM/TM   |    
| NA     | 
| > > >>>>    NA     |
| > > >>>> 
| |-----------++----------+-----------+-----------+-----------+-
| > > >>>> ----------|
| > > >>>> | Option 7  || Not-PCN  |    PCN    |   AM/TM   |    
| AfM    | 
| > > >>>>    NA     |
| > > >>>> 
| |-----------++----------+-----------+-----------+-----------+-
| > > >>>> ----------|
| > > >>>> | Option 8  || Not-PCN  |    PCN    |     AM    |    
| TM     | 
| > > >>>>    NA     |
| > > >>>> 
| |-----------++----------+-----------+-----------+-----------+-
| > > >>>> ----------|
| > > >>>> | Option 9  || Not-PCN  |    PCN    |     AM    |    
| TM     | 
| > > >>>>    AfM    |
| > > >>>>  
| > > >>>> 
| --------------------------------------------------------------
| > > >>>> ---------
| > > >>>>
| > > >>>>    Notes: Not-PCN means the packet is not PCN capable.
| > > >>>>
| > > >>>>           Figure 2: Encoding of PCN Information Using
| > DSCP Field
| > > >>>>
| > > >>>> 3.2.1.  Benefits of Using DSCP Field
| > > >>>>
| > > >>>>    The main benefit of using the DSCP field is that 
| it is not 
| > > >>>> affecting
| > > >>>>    the end-to-end ECN semantics and therefore the issues
| > > >>>>         
| > > >>> and concerns
| > > >>>       
| > > >>>>    raised in RFC 4774 [22] are not applicable for this
| > encoding
| > > >>>> scheme.
| > > >>>>    Another benefit is related to the fact that all 4
| > > DSCP encoding
| > > >>>>    options depicted in Figure 2 can support the PCN 
| capable not
| > > >>>>    congested (PCN) indication, the admission control
| > > (AM) and flow
| > > >>>>    termination (TM) encoding states.  In addition Option 8
| > > >>>>         
| > > >>> and 10 can
| > > >>>       
| > > >>>>    support the ECMP solution.
| > > >>>>
| > > >>>> 3.2.2.  Drawbacks of Using DSCP Field
| > > >>>>
| > > >>>>    This type of encoding needs to use per PHB, in
| > addition to the
| > > >>>>    original DSCP and depending on the encoding option used,
| > > >>>>         
| > > >>> one, two,
| > > >>>       
| > > >>>>    three, or four DSCP values, respectively.  These
| > > >>>>         
| > > >> additional DSCP
| > > >>     
| > > >>>>    values can be taken from the DSCP values that are not
| > > >>>>         
| > > >> defined by
| > > >>     
| > > >>>>    standards action, see RFC 2211 [9].  Note that all the
| > > >>>>         
| > > >> additional
| > > >>     
| > > >>>>    DSCP values are representing and are associated with one
| > > >>>>         
| > > >>> PHB.  The
| > > >>>       
| > > >>>>    value of this DSCP/PHB can either follow a standards
| > > action or
| > > >>>> use a
| > > >>>>    value that is applied for experimental or local 
| use.  It is 
| > > >>>> important
| > > >>>>    to note that the number of the DSCP values used 
| for local or
| > > >>>>    experimental use is restricted and therefore the 
| number of 
| > > >>>> different
| > > >>>>    PHBs supported in the PCN domain will also be restricted. 
| > > >>>>
| > > >>>> Best regards,
| > > >>>> Georgios
| > > >>>>
| > > >>>>
| > > >>>>         
| > > >>>>> -----Original Message-----
| > > >>>>> From: [email-masked] [mailto:[email-masked]] On
| > > >>>>>           
| > > >>>> Behalf Of
| > > >>>>         
| > > >>>>> [email-masked]
| > > >>>>> Sent: donderdag 21 februari 2008 10:24
| > > >>>>> To: [email-masked]; 
| > > >>>>> [email-masked]; [email-masked]
| > > >>>>> Cc: [email-masked]; [email-masked]
| > > >>>>> Subject: Re: [PCN] FW: RE: PCN encoding option
| > > >>>>>
| > > >>>>> Ingemar
| > > >>>>>
| > > >>>>> Re
| > > >>>>>
| > > >>>>>           
| > > >>>>>> consider the end to end ECN usecases
| > > >>>>>>             
| > > >>>>> I believe that the emails below about Toby's encoding
| > > >>>>>           
| > > >> proposal do
| > > >>     
| > > >>>>> indeed already consider ECN. Would appreciate it if you
| > > >>>>>           
| > > >> could add
| > > >>     
| > > >>>>> further text to it to better capture the (pros and) cons.
| > > >>>>>
| > > >>>>>           
| > > >>>>>> more DSCP codepoints
| > > >>>>>>             
| > > >>>>> I think you may be proposing an encoding that uses all dscp
| > > >>>>>           
| > > >>>> codepoints
| > > >>>>         
| > > >>>>> (as has Georgios). That's fine - but a "1 pager"
| > > >>>>> setting out this option with its pros and cons (ie
| > > >>>>>           
| > > >>> similar to what
| > > >>>       
| > > >>>>> toby has done below) is needed I think! At the moment we
| > > >>>>>           
| > > >>>> have lots of
| > > >>>>         
| > > >>>>> options on the table - in order to reach a decision, I
| > > >>>>>           
| > > >>>> think we really
| > > >>>>         
| > > >>>>> need very few options but with their pros and cons better
| > > >>>>>           
| > > >>> laid out.
| > > >>>       
| > > >>>>> I haven't managed to get to your draft yet, sorry (next week
| > > >>>>> hopefully)
| > > >>>>> -
| > > >>>>> Thanks
| > > >>>>> Phil
| > > >>>>>
| > > >>>>>
| > > >>>>>           
| > > >>>>>> -----Original Message-----
| > > >>>>>> From: Ingemar Johansson S
| > > >>>>>>             
| > > >>>> [mailto:[email-masked]]
| > > >>>>         
| > > >>>>>> Sent: 21 February 2008 06:43
| > > >>>>>> To: Eardley,PL,Philip,CXR9 R;
| > > >>>>>>             
| > > >> [email-masked];
| > > >>     
| > > >>>>>> Moncaster,T,Toby,CXR9 R
| > > >>>>>> Cc: [email-masked]; Briscoe,RJ,Bob,CXR9 R
| > > >>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option
| > > >>>>>>
| > > >>>>>> Hi
| > > >>>>>>
| > > >>>>>> In this discussion it may be well worth the effort to
| > > >>>>>>             
| > > >>>>> consider the end
| > > >>>>>           
| > > >>>>>> to end ECN usecases that we foresee when considering
| > > >>>>>>             
| > > >>> various PCN
| > > >>>       
| > > >>>>>> encoding options.
| > > >>>>>> Please have a look at
| > > >>>>>>
| > > >>>>>>             
| > > >> 
| > > 
| > 
| http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt
| > > >>     
| > > >>>>>> for a discussion of the use cases and a motivation to why
| > > >>>>>>             
| > > >>>> end to end
| > > >>>>         
| > > >>>>> ECN
| > > >>>>>           
| > > >>>>>> should be maintained even across PCN nodes even for non
| > > >>>>>>             
| > > >>>> DF traffic.
| > > >>>>         
| > > >>>>>> That said I realize that there is some cost associated to
| > > >>>>>>             
| > > >>>>> the use of
| > > >>>>>           
| > > >>>>>> DSCP codepoints, this cost must however be weighted against
| > > >>>>>>             
| > > >>>>> the risk
| > > >>>>>           
| > > >>>>>> that other functionality like end to end ECN semantics is
| > > >>>>>>             
| > > >>>> probably
| > > >>>>         
| > > >>>>>> broken if a PCN encoding option "fiddles" with the ECN
| > > >>>>>>             
| > > >>> bits. It is
| > > >>>       
| > > >>>>> easy
| > > >>>>>           
| > > >>>>>> to see that if one wish to maintain support for end to
| > > >>>>>>             
| > > >>>> end ECN (not
| > > >>>>         
| > > >>>>> only
| > > >>>>>           
| > > >>>>>> in DF class) it simply costs more DSCP codepoints.
| > > >>>>>> I am not explicitly saying don't do this or that but I wish
| > > >>>>>>             
| > > >>>>> to avoid a
| > > >>>>>           
| > > >>>>>> situation where one technique has to be avoided in favor of
| > > >>>>>>             
| > > >>>>> the other
| > > >>>>> as
| > > >>>>>           
| > > >>>>>> it may in the end prevent deployment of both. If one can
| > > >>>>>>             
| > > >>>>> yank the two
| > > >>>>>           
| > > >>>>>> together so much the better even though the cost e.g in
| > > >>>>>>             
| > > >>> DSCP code
| > > >>>       
| > > >>>>> points
| > > >>>>>           
| > > >>>>>> is regarded as higher.
| > > >>>>>>
| > > >>>>>> Regards
| > > >>>>>> Ingemar
| > > >>>>>>
| > > >>>>>>             
| > > >>>>>>> -----Original Message-----
| > > >>>>>>> From: [email-masked] [mailto:[email-masked]]
| > > >>>>>>>               
| > > >>>>> On Behalf
| > > >>>>>           
| > > >>>>>>> Of [email-masked]
| > > >>>>>>> Sent: den 20 februari 2008 17:44
| > > >>>>>>> To: [email-masked]; 
| [email-masked]
| > > >>>>>>> Cc: [email-masked]; [email-masked]
| > > >>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option
| > > >>>>>>>
| > > >>>>>>> Thanks Michael
| > > >>>>>>>
| > > >>>>>>> I agree with you that spending one DSCP value is quite
| > > >>>>>>>               
| > > >>>> expensive
| > > >>>>         
| > > >>>>>>> (not two, as one is spent anyway). I think the only way
| > > >>>>>>>               
| > > >>>> of really
| > > >>>>         
| > > >>>>>>> assessing this properly is for an alternative proposal
| > > >>>>>>>               
| > > >>>> (with pros
| > > >>>>         
| > > >>>>>>> and cons) that requires only one DSCP.
| > > >>>>>>> Then we can see where the consensus for the best
| > > >>>>>>>               
| > > >> (/least bad)
| > > >>     
| > > >>>>>>> encoding lies. Personally I have no axe to grind for
| > > >>>>>>>               
| > > >>> or against
| > > >>>       
| > > >>>>>>> either - I'm not yet convinced that the proposal below is
| > > >>>>>>>               
| > > >>>>> definitely
| > > >>>>>           
| > > >>>>>>> the way to go, until compared it in detail with other
| > > >>>>>>>               
| > > >>> proposals.
| > > >>>       
| > > >>>>>>> So I think it would be really useful to have a "1
| > > >>>>>>>               
| > > >> pager" for
| > > >>     
| > > >>>>>>> alternative
| > > >>>>>>> proposal(s) before the ietf, as I think this would make
| > > >>>>>>>               
| > > >>>>> Philadelphia
| > > >>>>>           
| > > >>>>>>> discussions more productive.
| > > >>>>>>>
| > > >>>>>>>
| > > >>>>>>> You're correct about one of the motivations
| > > >>>>>>>               
| > > >>>> (advantages) for this
| > > >>>>         
| > > >>>>>>> proposal (although I don't think the issues are exactly
| > > >>>>>>>               
| > > >>>>> the same for
| > > >>>>>           
| > > >>>>>>> 11 leakage as 01/10 leakage).
| > > >>>>>>>
| > > >>>>>>> Consider the case where 11 leaks out of the PCN
| > > >>>>>>>               
| > > >>> domain. If the
| > > >>>       
| > > >>>>>>> endpoints are ECN capable, then the ECN source slows
| > > >>>>>>>               
| > > >>>> down (seems
| > > >>>>         
| > > >>>>>>> reasonable). If they're not capable, then the impact
| > > >>>>>>>               
| > > >>>> outside the
| > > >>>>         
| > > >>>>>>> domain isn't any different to what would happen without
| > > >>>>>>>               
| > > >>>>> PCN-domain.
| > > >>>>>           
| > > >>>>>>> Consider the case where ECN-11 leaks into the PCN domain.
| > > >>>>>>> Then this will lead to either flow admission or
| > > >>>>>>>               
| > > >>>>> termination in the
| > > >>>>>           
| > > >>>>>>> PCN-domain. These are both safe, in that the reaction is
| > > >>>>>>>               
| > > >>>>> (I believe)
| > > >>>>>           
| > > >>>>>>> at least as severe as would happen in an all ECN world.
| > > >>>>>>> You mention that this might not terminate the ECN-11 flow 
| > > >>>>>>> specifically (some other flow might get 
| terminated instead).
| > > >>>>>>> I think this is true, though it also implies that [1]
| > > >>>>>>>               
| > > >>>>> end-to-end ECN
| > > >>>>>           
| > > >>>>>>> & PCN on the same flow really is useful, [2] the
| > > >>>>>>>               
| > > >> mechanism (eg
| > > >>     
| > > >>>>>>> tunnelling) to carry ECN-marking transparently across the
| > > >>>>>>>               
| > > >>>>> PCN-domain
| > > >>>>>           
| > > >>>>>>> has also failed, [3] the flows which are terminated
| > > >>>>>>>               
| > > >>> aren't other
| > > >>>       
| > > >>>>>>> ECN-11 flows that are also getting in due to the same 
| > > >>>>>>> misconfiguration.
| > > >>>>>>>
| > > >>>>>>> Best wishes
| > > >>>>>>> Phil
| > > >>>>>>>               
| > > >>>>>>>> -----Original Message-----
| > > >>>>>>>> From: Michael Menth
| > > >>>>>>>>                 
| > > >>> [mailto:[email-masked]]
| > > >>>       
| > > >>>>>>>> Sent: 20 February 2008 10:50
| > > >>>>>>>> To: Moncaster,T,Toby,CXR9 R
| > > >>>>>>>> Cc: [email-masked]; Eardley,PL,Philip,CXR9 R;
| > > >>>>>>>>                 
| > > >>>> [email-masked];
| > > >>>>         
| > > >>>>>>>> [email-masked]; [email-masked];
| > > >>>>>>>>                 
| > > >>>> [email-masked];
| > > >>>>         
| > > >>>>>>>> [email-masked]; Briscoe,RJ,Bob,CXR9 R
| > > >>>>>>>> Subject: Re: FW: RE: PCN encoding option
| > > >>>>>>>>
| > > >>>>>>>> Hi Toby,
| > > >>>>>>>>
| > > >>>>>>>> as I understand the proposal, the motivation is to
| > > >>>>>>>>                 
| > > >>>> avoid 01/10
| > > >>>>         
| > > >>>>>>>> codepoints as it is not good if they leak out of the
| > > >>>>>>>>                 
| > > >>>>> network since
| > > >>>>>           
| > > >>>>>>> 01/10
| > > >>>>>>>               
| > > >>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes.
| > > >>>>>>>>                 
| > > >>>>>>> However, there is
| > > >>>>>>>               
| > > >>>>>>>> the same problem with 11 marking, i.e. 11-packets
| > > >>>>>>>>                 
| > > >> may not be
| > > >>     
| > > >>>>> dropped
| > > >>>>>           
| > > >>>>>>> by
| > > >>>>>>>               
| > > >>>>>>>> ECN nodes outside the PCN domain although endpoints
| > > >>>>>>>>                 
| > > >>>> are not ECN
| > > >>>>         
| > > >>>>>>> capable.
| > > >>>>>>>               
| > > >>>>>>>> Even if 11-packets trigger flow termination, it is not
| > > >>>>>>>>                 
| > > >>>>>>> guaranteed that
| > > >>>>>>>               
| > > >>>>>>>> exactly the marked flow going over an overloaded
| > > >>>>>>>>                 
| > > >> ECN node is
| > > >>     
| > > >>>>>>> terminated.
| > > >>>>>>>               
| > > >>>>>>>> Just want to say that this solution wants to solve a
| > > >>>>>>>>                 
| > > >>>>> problem that
| > > >>>>>           
| > > >>>>>>> exists
| > > >>>>>>>               
| > > >>>>>>>> only in case of misconfiguration (leaking packets), but
| > > >>>>>>>>                 
| > > >>>>>>> does not fully
| > > >>>>>>>               
| > > >>>>>>>> achieve that objective. Therefore, I feel that
| > > >>>>>>>>                 
| > > >>>> spending two DSCP
| > > >>>>         
| > > >>>>>>> values
| > > >>>>>>>               
| > > >>>>>>>> is quite expensive.
| > > >>>>>>>>
| > > >>>>>>>> Regards,
| > > >>>>>>>>
| > > >>>>>>>>     Michael
| > > >>>>>>>>
| > > >>>>>>>> [email-masked] wrote:
| > > >>>>>>>>                 
| > > >>>>>>>>> All,
| > > >>>>>>>>>
| > > >>>>>>>>> Phil and I have just been discussing the encoding draft
| > > >>>>>>>>>                   
| > > >>>>>>> and feel we
| > > >>>>>>> may
| > > >>>>>>>               
| > > >>>>>>>>> have lit upon a neat solution that seems to have
| > > >>>>>>>>>                   
| > > >>>> lots of pros
| > > >>>>         
| > > >>>>> and
| > > >>>>>           
| > > >>>>>>> few
| > > >>>>>>>               
| > > >>>>>>>>> cons... In order to get a better feeling for this
| > > >>>>>>>>>                   
| > > >>>>>>> proposal I will go
| > > >>>>>>>               
| > > >>>>>>>>> through the simplified version without Affected
| > > >>>>>>>>>                   
| > > >>>> marking first:
| > > >>>>         
| > > >>>>>>>>> PCN Meaning		ECN 	 DSCP
| > > >>>>>>>>>
| > > >>>>>>>>> PCN capable		00	 PCN 1
| > > >>>>>>>>> Admission Mark	11	 PCN 1
| > > >>>>>>>>> Termination Mark	11/00	 PCN 2
| > > >>>>>>>>>
| > > >>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with
| > > >>>>>>>>>                   
| > > >>> the same PCN
| > > >>>       
| > > >>>>>>> behaviour
| > > >>>>>>>               
| > > >>>>>>>>> aggregate.
| > > >>>>>>>>>
| > > >>>>>>>>> Pros:
| > > >>>>>>>>>  o  Termination marking and admission marking are
| > > >>>>>>>>>                   
| > > >>>> independent,
| > > >>>>         
| > > >>>>> eg
| > > >>>>>           
| > > >>>>>>>>> termination marking can be done after a packet has been
| > > >>>>>>>>>                   
| > > >>>>> admission
| > > >>>>>           
| > > >>>>>>>>> marked. Therefore a router can write AM or TM without
| > > >>>>>>>>>                   
| > > >>>>>>> having to read
| > > >>>>>>> the
| > > >>>>>>>               
| > > >>>>>>>>> packet's PCN marking first, which is easier to
| > > >>>>>>>>>                   
| > > >>>>> implement. (Note:
| > > >>>>>           
| > > >>>>>>>>> Over-writing a TM with AM is not allowed for
| > > >>>>>>>>>                   
| > > >> 3SM & CL, see
| > > >>     
| > > >>>>>>>>> draft-charny-pcn-comparison.)
| > > >>>>>>>>>
| > > >>>>>>>>> o  This scheme avoids giving semantics to ECT(0) and
| > > >>>>>>>>>                   
| > > >>>>>>> ECT(1). This is
| > > >>>>>>>               
| > > >>>>>>>>> safest option if packets leak outside the PCN
| > > >>>>>>>>>                   
| > > >>> region, due to
| > > >>>       
| > > >>>>> some
| > > >>>>>           
| > > >>>>>>> fort
| > > >>>>>>>               
| > > >>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant
| > > >>>>>>>>>                   
| > > >>>>>>> for a single
| > > >>>>>>>               
| > > >>>>>>>>> domain deployment of PCN).
| > > >>>>>>>>>
| > > >>>>>>>>> o  It leaves open the possibility of using ECT(0) and
| > > >>>>>>>>>                   
| > > >>>>>>> ECT(1) in some
| > > >>>>>>>               
| > > >>>>>>>>> mysterious way in a future end-to-end PCN deployment
| > > >>>>>>>>>
| > > >>>>>>>>> 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.
| > > >>>>>           
| > > >>>>>>>>> o  Incremental deployment steps are possible [1]
| > > >>>>>>>>>                   
| > > >>>>> could deploy SM
| > > >>>>>           
| > > >>>>>>>>> initially and later AM/TM. Just add the second
| > > >>>>>>>>>                   
| > > >>>>>>> DSCP.
| > > >>>>>>>               
| > > >>>>>>>>> If a router isn't upgraded at the same time nothing
| > > >>>>>>>>>                   
| > > >>>>> too horrific
| > > >>>>>           
| > > >>>>>>>>> happens.
| > > >>>>>>>>> [2] could just deploy admission control & add
| > > >>>>>>>>>                   
| > > >>>>> termination later,
| > > >>>>>           
| > > >>>>>>> just by
| > > >>>>>>>               
| > > >>>>>>>>> adding a new DSCP; there is no need to change the
| > > >>>>>>>>>                   
| > > >>>>>>> encoding and check
| > > >>>>>>> for
| > > >>>>>>>               
| > > >>>>>>>>> backwards compatibility? Vice-versa is also ok?
| > > >>>>>>>>>
| > > >>>>>>>>> Cons:
| > > >>>>>>>>> o  It needs an extra DSCP, per PCN behaviour aggregate.
| > > >>>>>>>>>                   
| > > >>>>> (Although
| > > >>>>>           
| > > >>>>>>>>> possibly it's OK to use the same DSCP for TM for
| > > >>>>>>>>>                   
| > > >>>> all PCN BAs?)
| > > >>>>         
| > > >>>>>>>>> o  If a packet (in a PCN flow) arrives at the
| > > >>>>>>>>>                   
| > > >> egress with
| > > >>     
| > > >>>>>>> its ECN =
| > > >>>>>>> 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)
| > > >>>>>>>               
| > > >>>>>>>>> o  If the PCN-domain is operating multipath routing
| > > >>>>>>>>>                   
| > > >>>>>>> (ECMP) that uses
| > > >>>>>>> the
| > > >>>>>>>               
| > > >>>>>>>>> DSCP to select routes, then there may be mis-ordering
| > > >>>>>>>>>                   
| > > >>>>> of packets
| > > >>>>>           
| > > >>>>>>> within
| > > >>>>>>>               
| > > >>>>>>>>> a flow. This may be OK as (1) no-one has yet said
| > > >>>>>>>>>                   
| > > >>>> they know of
| > > >>>>         
| > > >>>>> an
| > > >>>>>           
| > > >>>>>>> ECMP
| > > >>>>>>>               
| > > >>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of
| > > >>>>>>>>>                   
| > > >>>>>>> mis-ordering
| > > >>>>>>> when
| > > >>>>>>>               
| > > >>>>>>>>> there is termination marking may be acceptable
| > > >>>>>>>>>
| > > >>>>>>>>> If Affected marking is needed then the scheme can be
| > > >>>>>>>>>                   
| > > >>>>> modified as
| > > >>>>>           
| > > >>>>>>>>> follows:
| > > >>>>>>>>>
| > > >>>>>>>>> PCN Meaning		ECN 	DSCP
| > > >>>>>>>>>
| > > >>>>>>>>> PCN capable		00	PCN 1
| > > >>>>>>>>> Admission Mark	11	PCN 1
| > > >>>>>>>>> Termination Mark	11	PCN 2
| > > >>>>>>>>> Affected Mark	00	PCN 2
| > > >>>>>>>>>
| > > >>>>>>>>> The pros for this scheme are broadly similar to
| > > >>>>>>>>>                   
| > > >> the above.
| > > >>     
| > > >>>>> However
| > > >>>>>           
| > > >>>>>>> there
| > > >>>>>>>               
| > > >>>>>>>>> is a new con which may or may not matter: If a packet is
| > > >>>>>>>>>                   
| > > >>>>> affected
| > > >>>>>           
| > > >>>>>>> marked
| > > >>>>>>>               
| > > >>>>>>>>> and a later node is doing admission marking then it will
| > > >>>>>>>>>                   
| > > >>>>>>> reset the
| > > >>>>>>>               
| > > >>>>>>>>> affected mark to a termination mark. Work would
| > > >>>>>>>>>                   
| > > >> be needed
| > > >>     
| > > >>>>>>> to see if
| > > >>>>>>> this
| > > >>>>>>>               
| > > >>>>>>>>> skews the results and causes significant
| > > >>>>>>>>>                   
| > > >>> over-termination or
| > > >>>       
| > > >>>>> not.
| > > >>>>>           
| > > >>>>>>>>> Please could people look through this scheme and
| > > >>>>>>>>>                   
| > > >>>>> highlight any
| > > >>>>>           
| > > >>>>>>>>> additional concerns that they may have (and extra
| > > >>>>>>>>>                   
| > > >>>>> benefits too).
| > > >>>>> I
| > > >>>>>           
| > > >>>>>>> would
| > > >>>>>>>               
| > > >>>>>>>>> like to get as many opinions as possible.
| > > >>>>>>>>>
| > > >>>>>>>>> What I want to avoid is people just emailing back with
| > > >>>>>>>>>                   
| > > >>>>>>> "why not try
| > > >>>>>>> this
| > > >>>>>>>               
| > > >>>>>>>>> scheme instead". Currently we seem to have a plethora of
| > > >>>>>>>>>                   
| > > >>>>> possible
| > > >>>>>           
| > > >>>>>>>>> schemes on the table and people need to start putting
| > > >>>>>>>>>                   
| > > >>>>> down much
| > > >>>>>           
| > > >>>>>>> clearer
| > > >>>>>>>               
| > > >>>>>>>>> pros and cons for the schemes they support... 
| > > >>>>>>>>>                   
| > > >> So it could
| > > >>     
| > > >>>>>>> be good to
| > > >>>>>>>               
| > > >>>>>>>>> have a similar "one page" email about a specific
| > > >>>>>>>>>                   
| > > >>> scheme that
| > > >>>       
| > > >>>>> only
| > > >>>>>           
| > > >>>>>>> uses
| > > >>>>>>>               
| > > >>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead.
| > > >>>>>>>>>
| > > >>>>>>>>> Toby
| > > >>>>>>>>>
| > > >>>>>>>>>                   
| > > >>> 
| > > 
| ____________________________________________________________________
| > > >>>       
| > > >>>>>>>>> Toby Moncaster, <[email-masked]>
| > > >>>>>>>>>                   
| > > >> Networks Research
| > > >>     
| > > >>>>>>> Centre, BT
| > > >>>>>>>               
| > > >>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44
| > > >>>>>>>>>                   
| > > >>> 1473 648734
| > > >>>       
| > > >>>>>>>> --
| > > >>>>>>>> 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
| > > >>>>>>>>                 
| > > >>>>>>> _______________________________________________
| > > >>>>>>> PCN mailing list
| > > >>>>>>> [email-masked]
| > > >>>>>>> http://www.ietf.org/mailman/listinfo/pcn
| > > >>>>>>>
| > > >>>>>>>               
| > > >>>>> _______________________________________________
| > > >>>>> PCN mailing list
| > > >>>>> [email-masked]
| > > >>>>> http://www.ietf.org/mailman/listinfo/pcn
| > > >>>>>
| > > >>>>>           
| > > >>>>
| > > >>>>         
| > > 
| > > --
| > > 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
| > > 
| > > 
| > 
| _______________________________________________
| PCN mailing list
| [email-masked]
| http://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Fri, 22 Feb 2008 11:58:49 +0100

Hi Toby,

resetting 01- and 10-marked packets to 00-marking does not conflict with 
RFC4774, only interchanging them is bad:

   A requirement for compatibility with end-nodes using default ECN is
   that if a packet that *could* be using default semantics is marked
   with the ECN codepoint "00", this marking must not be changed to
   "01", "10", or "11" in the network.  This prevents the packet from
   being represented incorrectly to a default-ECN router downstream as
   ECN-Capable.  Similarly, if a packet that *could* be using default
   semantics is marked with the ECN codepoint "01", then this codepoint
   should not be changed to "10" in the network (and a "10" codepoint
   should not be changed to "01").  This requirement is necessary to
   avoid interference with the transport protocol's use of the ECN nonce
   [RFC3540].

Regards,

	Michael

[email-masked] wrote:
>>> second option keeps it on the subpath before entering the 
>>>       
>> PCN domain.
>>>>> This is exactly the sort of thing Phil and I were hoping 
>>>>>           
>>> to trigger 
>>>       
>>>>> people to write in response to our email. We are hoping to 
>>>>>           
>>> settle on 
>>>       
>>>>> what are the real options people support for the 
>>>>>           
>> encoding and why 
>>     
>>>>> they support them...
>>>>>
>>>> Realized that this is one (big) problem, thanks for 
>>>>         
>>> pointing out this 
>>>       
>>>> issue.
>>>>
>>>> or something similar is given in the PCN encoding draft 
>>>>         
>> but I don't 
>>     
>>>> semantics to 100%, rather it assumes that negotiation of 
>>>>         
>> the use of 
>>     
>>>>>> Putting the issues with "leakage" aside (I cannot tell 
>>>>>>             
>>> how serious 
>>>       
>>>>>> this problem really is).
>>>>>>
>>>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE 
>>>>>>             
>> codepoint. The 
>>     
>>>>>> mark in wireless nodes by means of eg. SIP signaling. 
>>>>>>             
>>> Also, atleast 
>>>       
>>>>>> Besides this I would prefer a solution that maintains 
>>>>>>             
>> end to end 
>>     
>>>>>>> In my opinion the goal of the encoding draft is to 
>>>>>>>               
>> provide this 
>>     
>>>>>>> Phil and Ingemar, if you can add advantages, 
>>>>>>>               
>>> disadvantages to the 
>>>       
>>>>>>>    additional DSCP values and Option 10 needs four 
>>>>>>>               
>>> additional DSCP
>>>       
>>>>>>>    3rd, and 4th DSCP values are representing DSCP 
>>>>>>>               
>> values that are
>>     
>>>>>>>    assigned by IANA as DSCP experimental values, see RFC 
>>>>>>>               
>>> 2211 [9].
>>>       
>>>>>>>
>>>>>>>  
>>>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add 
>>>>>>>               
>> DSCP 3 Add 
>>     
>>>>>>> |DSCP 4
>>>>>>> || 
>>>>>>>           Figure 2: Encoding of PCN Information Using 
>>>>>>>               
>> DSCP Field
>>     
>>>>>>>    Another benefit is related to the fact that all 4 
>>>>>>>               
>>> DSCP encoding
>>>       
>>>>>>>    congested (PCN) indication, the admission control 
>>>>>>>               
>>> (AM) and flow
>>>       
>>>>>>>    This type of encoding needs to use per PHB, in 
>>>>>>>               
>> addition to the
>>

---

From: Michael Menth <[email-masked]>
Date: Fri, 22 Feb 2008 12:12:45 +0100

Hi Ingemar,

> without the nonce capability. 

The difficulty is that the information for each packet whether 10 or 01 
must be kept, that says RFC4774:

Similarly, if a packet that *could* be using default

This would require a per packet signalling ...

> or will the ECN bits be set to "00".
EF DSCP is remarked to PCN in any case.
1) 11-marked PCN packets are dropped by the PCN ingress
2) 11 is kept as is
and 01/10 marking is reset to 00 (no-precongestion). The PCN egress node 
resets 10/01 marked packets to 00. Therefore, the ECN capability for PCN 
traffic is lost
1) completely
2) for the partial downstream path starting with the PCN ingress node.

It's true that PCN marking can get problems if the majority of PCN 
packets was CE-marked when entering the PCN domain. This kind of traffic 
also cheats ECN when it doesn't back off. I just want to say: even TCP 
senders and receivers can cheat, do we care? The question is what's more 
important: remaining ECN functionality for the partial path up to the 
PCN ingress node or safety against too many 11-marked packets. I see 
these options (1 and 2) and have no particular preference.

Regards,

    Michael

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 22 Feb 2008 16:09:52 +0100

Hi Michael. 

Answer inline below.

> Sent: den 22 februari 2008 12:13
> To: Ingemar Johansson S
> >> this solution essentially spends a DSCP to save 11-marking through 
> >> the PCN domain and allow them to be PCN-marked. This is a 
> rather high 
> >> price, in particular because the PCN packets need to be 
> remarked to 
> >> 00. This has the consequence that ECN capability is lost 
> for the rest 
> >> of the path.
> >>     
> > the ECN capability is negotiated out of band for the wireless 
> > endpoints and the up and downlink wireless nodes, these 
> will be ECN-CE 
> > capable but without the nonce capability.
> >   
> 
> The difficulty is that the information for each packet 
> whether 10 or 01 must be kept, that says RFC4774:
> 

Not 100% convinced here, ECN codepoints "01" and "10" can be reset to
"00", that is my interpretation of 4.3 in RFC4774. 
What might be seen as odd is perhaps that after PCN egress the ECN
pattern using this trick will only use the code points "00" or "11"
instead of the normal "01", "10" and "11" (if ECN capable).
Routers located after PCN egress won't be able to set ECN "11" as the
flow is not anymore regarded as ECN capable (on IP level). Wireless
nodes such as LTE-eNB can however be instructed to set ECN "11" during
congestion as this then controlled using out of band signaling, this out
of band signaling is in turn controlled by policy rules that will limit
the risk for cheating.
Note that this is meant for realtime traffic and a means to do efficient
adaptation in a wireless enviroment where the transmission capacity for
a single user changes changes dynamically due to physical factors such
as shadowing et.c.

> >> The first option loses ECN capability for PCN traffic, the second 
> >> option keeps it on the subpath before entering the PCN domain.
> >>     
> > DSCP=EF. What about ECN="01" or "01" will these also be kept as 
> > DSCP=EF or will the ECN bits be set to "00".
> > Please explain.
> >   
> and 01/10 marking is reset to 00 (no-precongestion). The PCN 
> egress node resets 10/01 marked packets to 00. Therefore, the 
> ECN capability for PCN traffic is lost
> 1) completely
> It's true that PCN marking can get problems if the majority 
> of PCN packets was CE-marked when entering the PCN domain. 
> This kind of traffic also cheats ECN when it doesn't back 
> off. I just want to say: even TCP senders and receivers can 
> cheat, do we care? The question is what's more
> important: remaining ECN functionality for the partial path 
> up to the PCN ingress node or safety against too many 
> 11-marked packets. I see these options (1 and 2) and have no 
> particular preference.
> 
> Regards,
> 
>     Michael
> 
> >
> >
> >   
> >> Regards,
> >>
> >>     Michael
> >>

---

From: Michael Menth <[email-masked]>
Date: Fri, 22 Feb 2008 16:17:24 +0100

Hi Ingemar,

see inline.

Ingemar Johansson S wrote:
>>> Not sure that I agree, yes the ECT(0), ECT(1) codepoints 
>>>       
>> are lost and 
>>     
>>> there goes also the ECN nonce and the "inband" ECN 
>>>       
>> capability signaling.
>>     
>>> A router outside the PCN domain wont be able to set ECN-CE. 
>>>       
>> However if 
>>     

Ok, I see. I think this is a solution not standardized by the IETF and 
can be done for any encoding scheme. If not, what's its requirement on 
the encoding?

Regards,

    Michael

>>> ingress they are remarked as DSCP=PCN unless ECN="11", in 
>>>       
>> which case 
>>

---

From: <[email-masked]>
Date: Fri, 22 Feb 2008 15:24:52 -0000

Ingemar

Just catching up - haven't read all the thread, so sorry if this has
already been brought up.

you clear ECT to 00 at the ingress. therefore ecn [3168] doesn't work -
unless you take alternative action (Architecture draft describes the
possibilities, S3.5: [downgrade the packet to non PCN-BA, eg best
effort; tunnel the packet, so that the ECN-marking is carried
transparently across the PCN-domain.])
I don't see the fact that you carry 11 transparently makes any
difference to this. 

phil
this
> I would prefer to sacrifice the end to end ECN semantics for the
ECT(0)
> > encoding draft!
> > encoding scheme.
> > > > broken if a PCN encoding option "fiddles" with the ECN bits. It
is
> > > > together so much the better even though the cost e.g in DSCP
code
> > > > > encoding lies. Personally I have no axe to grind for or
against
proposals.
> > > > > > > PCN 1 and PCN 2 are 2 different codepoints with the same
PCN
> > > > > > > safest option if packets leak outside the PCN region, due
to
> > > > > > > skews the results and causes significant over-termination
or
> > > > > > > have a similar "one page" email about a specific scheme
that

---

From: <[email-masked]>
Date: Fri, 22 Feb 2008 15:44:05 -0000

Just a quick question relating to all this: What deployment scenarios do
people envisage as being sensible for the single-domain PCN solution we
are currently meant to be standardising? It strikes me that some of the
coding schemes are making assumptions about the nature of the network
topology either side of the PCN domain.

I actually do quite like Ingemar's scheme, especially in the modified
version using a parallel DSCP which provides a really elegant way to
tunnel 11 across the PCN region. One definite con (true for many
schemes) is that you have to read both the DSCP and the ECN fields
before you can decide how to mark (as you mustn't remark TM to AM). I am
still unclear exactly how Michael envisages metering these packets?
Would you meter them with other TM marks?

Toby 

> Sent: 22 February 2008 15:17
> To: Ingemar Johansson S
> >>>>>>>> | Option 6  || Not-PCN  |    PCN    |   AM/TM   |    
> NA     | 
> >>>>>>>>    NA     |
> >>>>>>>> 
> >>>>>>>> | Option 7  || Not-PCN  |    PCN    |   AM/TM   |    
> AfM    | 
> >>>>>>>>    NA     |
> >>>>>>>> 
> >>>>>>>> | Option 8  || Not-PCN  |    PCN    |     AM    |    
> TM     | 
> >>>>>>>>    NA     |
> >>>>>>>> 
> >>>>>>>> | Option 9  || Not-PCN  |    PCN    |     AM    |    
> TM     | 
> >>>>>>>>    AfM    |
> >>>>>>>>  
> >>>>>>>> 
> >>>>>>>>    The main benefit of using the DSCP field is that 
> it is not 
> >>>>>>>> affecting
> >>>>>>>>    value that is applied for experimental or local 
> use.  It is 
> >>>>>>>> important
> >>>>>>>>    experimental use is restricted and therefore the 
> number of 
> >>>>>>>> different

---

From: Michael Menth <[email-masked]>
Date: Fri, 22 Feb 2008 16:53:22 +0100

Hi Toby,

> Would you meter them with other TM marks?

All 11-marked packets would undergo the metering process with other NP, 
AM, and TM marked packets for admission metering, and they would also 
undergo the metering process with other NP, AM marked packets for 
termination metering.

But given the fact that this raises vulnerabilities, I tend towards 
dropping 11-marked packets at the ingress which essentially switches off 
ECN capability for PCN traffic and saves a codepoint (11). This pushes 
Phil's idea of "blind marking":
NP: 00
AM: 10
TM: 01
AM&TM: 11
The marker does not need to read the ECN bits before marking. Well, 
actually this is not true because only NP and AM packets should be 
respected for TM marking ... maybe not so helpful then as this applies 
only to AM-marking. Saving a codepoint might possibly be better for 
future use such as AffM?

Regards,

    Michael

>>>>>> this solution essentially spends a DSCP to save 
>>>>>>             
>> 11-marking through 
>>     
>>>>    should not be changed to "10" in the network (and a 
>>>>         
>> "10" codepoint
>>     
>>>>    should not be changed to "01").  This requirement is 
>>>>         
>> necessary to
>>     
>>> Not 100% convinced here, ECN codepoints "01" and "10" can 
>>>       
>> be reset to
>>     
>>> Routers located after PCN egress won't be able to set ECN 
>>>       
>> "11" as the
>>     
>>> nodes such as LTE-eNB can however be instructed to set ECN 
>>>       
>> "11" during
>>     
>>> congestion as this then controlled using out of band 
>>>       
>> signaling, this out
>>     
>>> of band signaling is in turn controlled by policy rules 
>>>       
>> that will limit
>>     
>>> the risk for cheating.
>>> Note that this is meant for realtime traffic and a means to 
>>>       
>> do efficient
>>     
>>> adaptation in a wireless enviroment where the transmission 
>>>       
>> capacity for
>>     
>>> a single user changes changes dynamically due to physical 
>>>       
>> factors such
>>     
>>> as shadowing et.c.
>>>   
>>>       
>>>>>> 1) discard 11-marked PCN packets before entering the PCN 
>>>>>>             
>> domain OR
>>     
>>>>>> 2) let them go through the PCN domain, take them into 
>>>>>>             
>> account for 
>>     
>>>>>> The first option loses ECN capability for PCN traffic, 
>>>>>>             
>> the second 
>>     
>>>> 2) for the partial downstream path starting with the PCN 
>>>>         
>> ingress node.
>>     
>>>>>>> think so as this alternative does not preserve the end 
>>>>>>>               
>> to end ECN 
>>     
>>>>>>>>> I would prefer to sacrifice the end to end ECN 
>>>>>>>>>                   
>> semantics for the
>>     
>>>>>>>>> One would then end up with a PCN encoding schema like 
>>>>>>>>>                   
>> (I beleve 
>>     
>>>>>>>>> option 5 in figure 1 in the PCN encoding draft) is 
>>>>>>>>>                   
>> the closest.
>>     
>>>>>>>>> PCN Meaning		ECN 	 DSCP
>>>>>>>>>> In order to make a selection of one single (or two) 
>>>>>>>>>>                     
>> options, I 
>>     
>>>>>>>>>> ones already mentioned below in Section 3.2.1 and 
>>>>>>>>>>                     
>> 3.2.2 of the 
>>     
>> --------------------------------------------------------------
>>     
>>>>>>>>>> ---------
>> |-----------++----------+-----------+-----------+-----------+-
>>     
>>>>>>>>>> ----------|
>> |-----------++----------+-----------+-----------+-----------+-
>>     
>>>>>>>>>> ----------|
>> |-----------++----------+-----------+-----------+-----------+-
>>     
>>>>>>>>>> ----------|
>> --------------------------------------------------------------
>>     
>>>>>>>>>> ---------
>>>>>>>>>>
>>>>>>>>>>    options depicted in Figure 2 can support the PCN 
>>>>>>>>>>                     
>> capable not
>>     
>>>>>>>>>>    to note that the number of the DSCP values used 
>>>>>>>>>>                     
>> for local or
>>     
>>>>>>>>>>>>> To: [email-masked]; 
>>>>>>>>>>>>>                           
>> [email-masked]
>>     
>>>>>>>>>>>>> specifically (some other flow might get 
>>>>>>>>>>>>>                           
>> terminated instead).
>>

---

From: <[email-masked]>
Date: Fri, 22 Feb 2008 18:13:52 -0000

3 replies below to snippets from this thread
phil

> RFC4774, only interchanging them is bad:

don't agree. Swapping 01 & 10 breaks the ecn nonce. But setting ect [10
or 01] to 00 turns off ECN 3168. since 3168 is a STD, this is a problem.

>    avoid interference with the transport protocol's use of the ECN
nonce

----
> a single user changes changes dynamically due to physical factors such
think the talk about future uses of ECN by wireless users is a bit
speculative. Worrying about things that are ietf stds already is hard
enough!

-----
> The next alternative is then
this could be directly compared with toby's scheme, in that they both
use ECN & 2 DSCPs.

So I copied in the pros and cons that toby claims for his scheme, &
added some remarks below to compare with your idea
> termination marking can be done after a packet has been admission
marked.
> Therefore a router can write AM or TM without having to read the
packet's
> PCN marking first, which is easier to implement. (Note: Over-writing a
TM
> with AM is not allowed for 3SM & CL, see draft-charny-pcn-comparison.)
your scheme doesn't have this pro 
of
> misconfiguration of the PCN-boundary-nodes (relevant for a single
domain
> deployment of PCN).
see issue above about loss of 3168 semantics.
DSCP.
happens.
for
> backwards compatibility? Vice-versa is also ok?
This pro is lost
> o  It needs an extra DSCP, per PCN behaviour aggregate. (Although
possibly
> it's OK to use the same DSCP for TM for all PCN BAs?)
> 
and
> it really is required to preserve this info across the PCN-domain,
then
> some complexity is needed at the PCN-boundary-nodes (tunnelling)
you're trying to avoid this con, which is a noble aim & would be nice if
succeed, although I don't think you've managed it
the
> DSCP to select routes, then there may be mis-ordering of packets
within a
> flow. This may be OK as (1) no-one has yet said they know of an ECMP
when
> there is termination marking may be acceptable
point (2) doesn't hold for your scheme 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Sat, 23 Feb 2008 12:46:05 +0100

Hi Phil,

>> resetting 01- and 10-marked packets to 00-marking does not conflict
>>     
> with
>   

Yes, this turns off 3168, but why is that bad? I don't see that rfc4774 
forbids it.

Regards,

    Michael

>>    semantics is marked with the ECN codepoint "01", then this
>>     
> codepoint
>   
>>    avoid interference with the transport protocol's use of the ECN
>>     
> nonce
>   
>>    [RFC3540].
>>
>> Regards,
>>
>> 	Michael