Subject: Re: [PCN] Application of 3-in-1 to a single marking scheme

From: <[email-masked]>
Date: Thu, 1 Jul 2010 10:24:39 +0200

Hi Michael, 

thanks for pointing out. Only applying threshold marking for admission control 
in an MPLS network indeed seems interesting to me.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Tuesday, June 29, 2010 9:01 PM
To: Bob Briscoe
Cc: pcn
Subject: Re: [PCN] Application of 3-in-1 to a single marking scheme

Hi Bob,

Bob Briscoe schrieb:
> Michael,
>
> I thought single-marking only ever uses the excess-traffic marking algo?
Depends which "Single Marking" you are talking about ;-)
1) There is the SM edge behavior which uses only excess-traffic-marking
2) There is the admission control aspect of the CL edge behavior which 
requires only threshold-marking. It was often discussed that this 
feature may be deployed also without flow termination especially in MPLS 
networks when a third pcn codepoint is just not available. I think that 
was often Ruediger's  and Joe's point. For this case it makes sense to 
enable only threshold marking.

>
> Then marking algos can be hard-coded (ie no config needed) so ETM 
> always marks CE and ThM (if used) always marks ECT(1).
>
> Is threshold marking ever used for single marking? Or is there any 
> proposed scheme (that has been simulated and it works) where threshold 
> marking alone is used?
Yes, see 2) above.

Regards,

    Michael

>
> * If there is, then we need to cater for a)ii) and b)ii).
> * If there is not, but someone might want to try theshold marking 
> alone in future, then that someone shouldn't expect to do something 
> experimental without any configuration. Ie. they have to ask their 
> router vendor to allow them to:
>   - either config their routers to encode threshold markings as CE 
> [a)ii)]
>   - or upgrade their tunnels to comply with ecn-tunnel [b)ii)]
>
> Or am I missing something?
>
>
> Bob
>
> At 15:29 29/06/2010, Michael Menth wrote:
>> Hi Bob, Toby, and all,
>>
>> in 3-in-1 encoding we have the following mapping to ECN codepoints:
>>
>> not-ECT: not-PCN
>> ECT(0):  not-marked (NM)
>> ECT(1):  threshold-marked (ThM)
>> CE:      excess-traffic-marked (ETM)
>>
>> 3-in-1 encoding can also be used with only a single marking scheme so 
>> that packets are re-marked to either ETM or ThM. Here we have two 
>> fundamentally different encoding options:
>>
>> a) baseline style
>>
>> i) for excess-traffic-marking
>> not-ECT: not-PCN
>> ECT(0):  not-marked (NM)
>> CE:      excess-traffic-marked (ETM)
>>
>> ii) for threshold-marking
>> not-ECT: not-PCN
>> ECT(0):  not-marked (NM)
>> CE:      excess-traffic-marked (ETM)
>>
>> Here, only two codepoints are effectively used for pcn encoding 
>> (ECT(0) and CE). When interior nodes perform threshold-marking, they 
>> need to know whether the three-state 3-in-1 encoding is used or the 
>> two-state 3-in-1 encoding to re-mark packets correctly. Thus, 
>> interior nodes need to be configured with the exact encoding option 
>> (three-state, a.i or a.ii). The advantage of this encoding scheme is 
>> that it works well with old tunnels.
>>
>>
>> b) "no-encoding-config" style
>>
>> i) for excess-traffic-marking
>> not-ECT: not-PCN
>> ECT(0):  not-marked (NM)
>> CE:      excess-traffic-marked (ETM)
>>
>> ii) for threshold-marking
>> not-ECT: not-PCN
>> ECT(0):  not-marked (NM)
>> ECT(1):  excess-traffic-marked (ETM)
>>
>> Here, three codepoints are effectively blocked for pcn encoding 
>> (ECT(0), ECT(1), and CE). With this encoding option, interior nodes 
>> just need to know that 3-in-1 encoding is used and do not need to be 
>> configured with any more information (such as three-state or b.i or 
>> b.ii). The drawback is that threshold-marking does not work with 
>> old-fashion tunnels.
>>
>>
>> When going from PCN encoding from IP headers to shim headers in MPLS, 
>> a "no-config" style cannot be maintained as it blocks 3 pcn 
>> codepoints which is too expensive when only two of them are 
>> effectively used. Therefore, LSRs need to be configured anyway 
>> whether three-state encoding or two-state encoding using option i) or 
>> ii) is used.
>>
>>
>> Is my analysis clear and do you share it? What should be the 
>> consequence for a two-state limitation of 3-in-1 encoding? Is a) or 
>> b) more clever for two-state pcn in IP? It probably boils down to the 
>> question whether legacy tunnels are more important than 
>> "no-encoding-config" for IP equipment.
>>
>> Best wishes,
>>
>>    Michael
>>
>> -- 
>> PD Dr. habil. Michael Menth, Assistant Professor
>> University of Wuerzburg, Institute of Computer Science
>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
>> mailto:[email-masked]
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 

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

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

---

From: <[email-masked]>
Date: Thu, 1 Jul 2010 10:35:55 +0200

Hi Michael,

I'm not sure whether any complexity is possible at all. Some MPLS domains support 
"pen ultimate hop popping", meaning that the MPLS top label is popped before the 
packet reaches the Label Edge system. As far as I understand, downpropagation of 
MPLS TC encodings must be straightforward in this case and may not allow 
many configuration options.

a) baseline style seem to be simpler.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Tuesday, June 29, 2010 4:30 PM
To: Bob Briscoe; Toby Moncaster; pcn
Subject: [PCN] Application of 3-in-1 to a single marking scheme

Hi Bob, Toby, and all,

 not-ECT: not-PCN
 ECT(0):  not-marked (NM)

a) baseline style

Here, only two codepoints are effectively used for pcn encoding (ECT(0) 
and CE). When interior nodes perform threshold-marking, they need to 
know whether the three-state 3-in-1 encoding is used or the two-state 
3-in-1 encoding to re-mark packets correctly. Thus, interior nodes need 
to be configured with the exact encoding option (three-state, a.i or 
a.ii). The advantage of this encoding scheme is that it works well with 
old tunnels.

Here, three codepoints are effectively blocked for pcn encoding (ECT(0), 
ECT(1), and CE). With this encoding option, interior nodes just need to 
know that 3-in-1 encoding is used and do not need to be configured with 
any more information (such as three-state or b.i or b.ii). The drawback 
is that threshold-marking does not work with old-fashion tunnels.

When going from PCN encoding from IP headers to shim headers in MPLS, a 
"no-config" style cannot be maintained as it blocks 3 pcn codepoints 
which is too expensive when only two of them are effectively used. 
Therefore, LSRs need to be configured anyway whether three-state 
encoding or two-state encoding using option i) or ii) is used.

Is my analysis clear and do you share it? What should be the consequence 
for a two-state limitation of 3-in-1 encoding? Is a) or b) more clever 
for two-state pcn in IP? It probably boils down to the question whether 
legacy tunnels are more important than "no-encoding-config" for IP 
equipment.

Best wishes,

    Michael