Subject: [PCN] Possible clever encoding for PCN

From: <[email-masked]>
Date: Wed, 12 Mar 2008 23:11:27 -0000

Hi All,

Bob and I just spent a fun 30 minutes trying to work out how to carry
end-to-end ECN across PCN whilst still retaining all the PCN codepoints
we need. We think we have succeeded...

The attached 2 slides try to set this encoding out as clearly as
possible. Note the new terminology being used! Also note that this is
making the assumption that we will be re-using Fred Baker's DSCP and
hence need to identify PCN traffic from not PCN traffic.

Toby
____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

(in case anyone is wondering at the title it stands for: you can please
everyone all the time...)
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Thu, 13 Mar 2008 00:30:06 +0100

Hi Toby, hi Bob,

yes, that's good.

Side effects:
1) It disables ECN for EF-ADMIT if DSCPx is not available in the initial 
deployment model, but this holds for any encoding we considered so far 
unless we consumed at least 2 DSCPs.
2) When ECN is supported in the 3-codepoint model, endpoint of EM marked 
flows get 11 (CE) signals from PCN. This is not too bad as packets get 
marked in the 3-codepoint model only under heave overload. It's not 
problematic for most realtime flows that are not responsive to ECN anyway.

Regards,

    Michael

[email-masked] wrote:
> ------------------------------------------------------------------------
>

-- 
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: Bob Briscoe <[email-masked]>
Date: Thu, 13 Mar 2008 04:46:43 +0000

Michael,

[Terminology reminder at end.]

1) is true.
2) is a deliberate feature

You will also notice (Toby omitted to mention) that, not only does 
endpoint get EM marks as CE, but it gets ThM as CE too. We've made 
the egress rules so that all PCN marking is deliberately leaked out 
into the next non-PCN region. If there's more than one PCN region on 
the path, at each new PCN ingress, the previously leaked out CE are 
set aside in the NM(CE) codepoint, while more PCN markings are 
collected across the next region. Then, at the next egress, any CE 
set aside at the ingress or any PCN marks collected across the next 
PCN region are again deliberately leaked out as CE. And so on.

The upshot is that the endpoint sees all ECN markings and all PCN 
markings. This might seem strange, because each PCN region already 
responds to markings generated within each PCN region. But the idea 
is that, if the endpoints are adaptive, they /may/ be able to drop 
down a codec level when they see any CE marking (whether from PCN 
ThM, PCN EM or ECN). Then the PCN markings should go away. If the 
codecs don't or can't adapt, the PCN mechanisms will still be there.

To be absolutely clear, this is brainstorm stuff. We have no idea 
whether the three congestion control mecahnisms (adaptive codecs, PCN 
admission control and flow termination at overload) can reliably work 
together without fighting or thrashing etc. This is just wire 
protocol possibilities, not system design.

Terminology reminder:
NM = Not Marked
ThM = Threshold Marked
EM = Excess-rate Marked

Bob

> > hence need to identify PCN traffic from not PCN traffic.

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 13 Mar 2008 09:47:26 +0100

Bob,

the proposed codepoint scheme is clearly a progress and I like the 
idea of allowing end to end CE communication for PCN traffic. 

A few questions for my understanding:

Please clarify, whether packets use a single DSCP between 
domains or different ones. I can't read that from the table.
If two DSCPs are assumed, it is intentional to remark 
ECT-EM packets to PCN-CE (i.e. change the DSCP at domain 
boundaries, see ingress transition definition)?

'Not-ECT' means 'PCN_and_Not-ECT' (in contrast to 'Not-PCN'
and 'Not-PCN_and_ECT'). There's no such thing as 
'PCN_and_ECT'?

The ThM marked packets travel end to end as CE (which means 
the new design tries to reduce bandwidth instead of stopping 
admission).

As an MPLS friend, one comment is whether it may be favourable 
to use  DSCPx  01 and 10 to codepoints to identify NM(Not-ECT) 
and NM(CE). If RFC 5129 is supported, an ECT 10 or 01 field is 
allowed to be changed to 11, but not the 00 codepoint 
(RFC 5129 demands a drop). 

Communication of the end-system support of CE indications is a 
matter of end systems. SIP provides the required mechanisms, 
I'm not absolutely sure about RTSP.

Regards,

Rudiger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of Bob Briscoe
| Sent: Thursday, March 13, 2008 5:47 AM
| To: [email-masked]
| Cc: [email-masked]
| Subject: Re: [PCN] Possible clever encoding for PCN
| 
| Michael,
| 
| [Terminology reminder at end.]
| 
| 1) is true.
| 2) is a deliberate feature
| 
| You will also notice (Toby omitted to mention) that, not only 
| does endpoint get EM marks as CE, but it gets ThM as CE too. 
| We've made the egress rules so that all PCN marking is 
| deliberately leaked out into the next non-PCN region. If 
| there's more than one PCN region on the path, at each new PCN 
| ingress, the previously leaked out CE are set aside in the 
| NM(CE) codepoint, while more PCN markings are collected 
| across the next region. Then, at the next egress, any CE set 
| aside at the ingress or any PCN marks collected across the 
| next PCN region are again deliberately leaked out as CE. And so on.
| 
| The upshot is that the endpoint sees all ECN markings and all 
| PCN markings. This might seem strange, because each PCN 
| region already responds to markings generated within each PCN 
| region. But the idea is that, if the endpoints are adaptive, 
| they /may/ be able to drop down a codec level when they see 
| any CE marking (whether from PCN ThM, PCN EM or ECN). Then 
| the PCN markings should go away. If the codecs don't or can't 
| adapt, the PCN mechanisms will still be there.
| 
| To be absolutely clear, this is brainstorm stuff. We have no 
| idea whether the three congestion control mecahnisms 
| (adaptive codecs, PCN admission control and flow termination 
| at overload) can reliably work together without fighting or 
| thrashing etc. This is just wire protocol possibilities, not 
| system design.
| 
| Terminology reminder:
| NM = Not Marked
| ThM = Threshold Marked
| EM = Excess-rate Marked
| 
| Bob
| 
| At 23:30 12/03/2008, Michael Menth wrote:
| >Hi Toby, hi Bob,
| >
| >yes, that's good.
| >
| >Side effects:
| >1) It disables ECN for EF-ADMIT if DSCPx is not available in the 
| >initial deployment model, but this holds for any encoding we 
| considered 
| >so far unless we consumed at least 2 DSCPs.
| >2) When ECN is supported in the 3-codepoint model, endpoint of EM 
| >marked flows get 11 (CE) signals from PCN. This is not too bad as 
| >packets get marked in the 3-codepoint model only under heave 
| overload. 
| >It's not problematic for most realtime flows that are not 
| responsive to ECN anyway.
| >
| >Regards,
| >
| >     Michael
| >
| >[email-masked] wrote:
| > > Hi All,
| > >
| > > Bob and I just spent a fun 30 minutes trying to work out how to 
| > > carry end-to-end ECN across PCN whilst still retaining 
| all the PCN 
| > > codepoints we need. We think we have succeeded...
| > >
| > > The attached 2 slides try to set this encoding out as clearly as 
| > > possible. Note the new terminology being used! Also note 
| that this 
| > > is making the assumption that we will be re-using Fred 
| Baker's DSCP 
| > > and hence need to identify PCN traffic from not PCN traffic.
| > >
| > > Toby
| > > 
| ____________________________________________________________________
| > > Toby Moncaster, <[email-masked]> Networks Research 
| Centre, BT 
| > > B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
| > >
| > >
| > >
| > > (in case anyone is wondering at the title it stands for: you can 
| > > please everyone all the time...)
| > > 
| --------------------------------------------------------------------
| > > ----
| > >
| > > _______________________________________________
| > > PCN mailing list
| > > [email-masked]
| > > https://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]
| >https://www.ietf.org/mailman/listinfo/pcn
| 
| ______________________________________________________________
| ______________
| Bob Briscoe, <[email-masked]>      Networks Research 
| Centre, BT Research
| B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    
| +44 1473 645196 
| 
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 13 Mar 2008 14:48:38 +0100

Hi

As a general 1st comment I am (slightly) positive to this approach. 

There is a certain risk that codecs over-react as ThM will be seen as
ECN-CE by the endpoints but here I lack the knowledge in how common ThM
will actually be compared to the experienced congestion experienced in
e.g wireless nodes outside the PCN domain. 
One scenario:
Video with two possible bitrate (200kbps and 50kbps), initially the
codec rate is 200kbps. 
As more flows are admitted endpoints will eventually see the ThM (masked
as ECN-CE). 
Some (or many or all?) of the endpoints will then adapt the codec rate
to the lower codec rate (50kbps, after a while as the rate change
effects, the ThM will go away and more flows will get admitted (with
initial codec rate 200kbps) with the result that endpoints will again
after while see ThM.... with the result that more endpoints adapt the
rate to the lower rate.
This can be both good and bad I guess, good in the sense that it is
maybe codec rate adaptivity at its best, bad in the sense that in the
end quality is generally sacrificed for capacity and the endpoints that
don't do rate adaptation at all are the winners. 
In a scenario with "trusted" enpoints that follow a secified adaptation
behavior this may however work. 

/Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Briscoe
> Sent: den 13 mars 2008 00:47
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] Possible clever encoding for PCN
> 
> Michael,
> 
> You will also notice (Toby omitted to mention) that, not only 
> does endpoint get EM marks as CE, but it gets ThM as CE too. 
> We've made the egress rules so that all PCN marking is 
> deliberately leaked out into the next non-PCN region. If 
> there's more than one PCN region on the path, at each new PCN 
> ingress, the previously leaked out CE are set aside in the 
> NM(CE) codepoint, while more PCN markings are collected 
> across the next region. Then, at the next egress, any CE set 
> aside at the ingress or any PCN marks collected across the 
> next PCN region are again deliberately leaked out as CE. And so on.
> 
> The upshot is that the endpoint sees all ECN markings and all 
> PCN markings. This might seem strange, because each PCN 
> region already responds to markings generated within each PCN 
> region. But the idea is that, if the endpoints are adaptive, 
> they /may/ be able to drop down a codec level when they see 
> any CE marking (whether from PCN ThM, PCN EM or ECN). Then 
> the PCN markings should go away. If the codecs don't or can't 
> adapt, the PCN mechanisms will still be there.
> 
> To be absolutely clear, this is brainstorm stuff. We have no 
> idea whether the three congestion control mecahnisms 
> (adaptive codecs, PCN admission control and flow termination 
> at overload) can reliably work together without fighting or 
> thrashing etc. This is just wire protocol possibilities, not 
> system design.
> 
> Terminology reminder:
> NM = Not Marked
> ThM = Threshold Marked
> EM = Excess-rate Marked
> 
> Bob
> 
> >1) It disables ECN for EF-ADMIT if DSCPx is not available in the 
> >initial deployment model, but this holds for any encoding we 
> considered 
> >so far unless we consumed at least 2 DSCPs.
> >2) When ECN is supported in the 3-codepoint model, endpoint of EM 
> >marked flows get 11 (CE) signals from PCN. This is not too bad as 
> >packets get marked in the 3-codepoint model only under heave 
> overload. 
> >It's not problematic for most realtime flows that are not 
> responsive to ECN anyway.
> >
> >Regards,
> >
> >     Michael
> >
> > > Bob and I just spent a fun 30 minutes trying to work out how to 
> > > carry end-to-end ECN across PCN whilst still retaining 
> all the PCN 
> > > codepoints we need. We think we have succeeded...
> > >
> > > possible. Note the new terminology being used! Also note 
> that this 
> > > is making the assumption that we will be re-using Fred 
> Baker's DSCP 
> > > and hence need to identify PCN traffic from not PCN traffic.
> > >
> > > Toby
> > > 
> > > (in case anyone is wondering at the title it stands for: you can 
> > > please everyone all the time...)
> > > 
> >University of Wuerzburg, Institute of Computer Science Am Hubland, 
> >D-97074 Wuerzburg, Germany, room B206

---

From: Michael Menth <[email-masked]>
Date: Fri, 14 Mar 2008 03:03:23 +0100

Hi Ingemar, hi Bob,

if the admissible rate is exceeded on the bottleneck link, all packets 
are ThM- or EM-marked. The egress resets their markings to CE. Isn't 
that a bit tough for already admitted PCN flows that use TCP and are 
responsive to ECN? They need to reduce their rate and as a consequence, 
they cannot benefit from PCN-based admission control. Do I miss something?

Regards,

    Michael

Ingemar Johansson S wrote:
>>>> Toby Moncaster, <[email-masked]> Networks Research 
>>>>         
>> Centre, BT 
>>     
>> --------------------------------------------------------------------
>>     
>>>> ----
>>>>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sat, 29 Mar 2008 19:15:19 -0400

Toby, Bob,
I like your approach and would like to suggest a minor modification.

EF-admit is used for admission control with the ECN bits being used in
the following way:
ECN = 00 Not-PCN-capable meaning that admission control is done some
other way.
ECN = 10 or 01 (ECT) means that PCN based admission control will be done
on these packets.
ECN = 11 (CE) means that admission control traffic (PCN and non-PCN) is
above the configured admission threshold and no additional flows should
be admitted. 
Note: If PCN wg decides to use the EF-admit codepoint it needs consider
traffic that is admission control via other means passing through the
network. 

Networks that wish to support flow termination they use a DSCP to signal
that state to indicate that some flows need to be terminated. This
approach reduces the risk if there are ECMP implementations which may
cause mis-ordering of packets of flows that may be terminated. Should
mis-ordering occur it will be very infrequent event.

Should also point out to the PCN wg that 3sm approach for flow
termination marking in seniors where changing DSCP for flow termination
cause route change will only mis-order one packet of a flow that is to
be terminated. Packets of flows that that are not going to be terminated
will not be mis-ordered. 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: March 12, 2008 7:11 PM
To: [email-masked]
Subject: [PCN] Possible clever encoding for PCN

Hi All,

Toby