Subject: [PCN] Encoding options with 2 DSCPs and limited ECN

From: Michael Menth <[email-masked]>
Date: Tue, 11 Mar 2008 19:45:00 +0100

Hi,

I had a short brainstorming with Bob and Toby discussing the few 
remaining encoding options when we go with an encoding using 2 DSCPs and 
reusing ECN bits.

Here is the result:
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/PCN-Encoding.pdf

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

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 11 Mar 2008 20:48:39 +0100

A short question.

If I understand this approach correctly the ECT is broken at PCN
ingress. Is this correct ? 

/Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Menth
> Sent: den 11 mars 2008 14:45
> To: pcn
> Subject: [PCN] Encoding options with 2 DSCPs and limited ECN
> 
> Hi,
> 
> I had a short brainstorming with Bob and Toby discussing the 
> few remaining encoding options when we go with an encoding 
> using 2 DSCPs and reusing ECN bits.
> 
> Here is the result:
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 12 Mar 2008 10:00:37 +0100

Hi Michael,

I'm a bit lost here. You only discuss tunneling or is this a general proposal?
The tunnel is PCN and it carries packets which are non PCN (i.e. ECN or ECN 
and other traffic)?

Is the interpretation of DSCP1 + 00 = PCN aware?

In the case of the example on slide with page number 10 (the forth page),
How can an a node tell when it should transition from NP to AM and when 
from NP to CE? This requires flow awareness, doesn't it?

Finally, in your last slide, first arrow, first and second bullet point:

First you say, that Non-PCN traffic backs off, then you claim that Non-PCN 
traffic grabs bandwidth from PCN traffic. This seems to be contradicting.
In termination state, non new flows are admitted. The idea is, to reduce 
traffic. Some flows do so by reducing bandwidth, others can't and therefore 
a few of them are terminated. If the end to end type of traffic reduces 
bandwidth consumption by 40% as a reaction on "11" and the PCN flows reduce 
bandwidth by 30% due to TM indications (the flows not terminated don't 
reduce bandwidth), then the non PCN flows don't seem to grab bandwidth 
from PCN flows.

Further, I'd like to know which of the following scenarios you have
considered during your discussion:

The PCN PHB is assumed to be acessible by
- an ECN aware application not using a PCN aware control plane.
- a non ECN aware application not using a PCN aware control plane.
- an ECN aware application using a PCN aware control plane.
- a non ECN aware application using a PCN aware control plane.

Regards,

Rudiger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of Michael Menth
| Sent: Tuesday, March 11, 2008 7:45 PM
| To: pcn
| Subject: [PCN] Encoding options with 2 DSCPs and limited ECN
| 
| Hi,
| 
| I had a short brainstorming with Bob and Toby discussing the 
| few remaining encoding options when we go with an encoding 
| using 2 DSCPs and reusing ECN bits.
| 
| Here is the result:
| http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio
| ns/PCN-Encoding.pdf
| 
| 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
| 
| _______________________________________________
| 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: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 12 Mar 2008 12:26:18 +0000

Hi all

Regarding the decission that is pending on the selection of the
PCN solutions/schemes I would like to propose the following:

1) Solutions that should be standardized a.s.a.p.:
CL-PHB + SM (Single Marking) with:
 * Admission control decission at the egress.
 * Flow termination decission at the ingress

However, the architecture draft should:
 * Allow the possibility that in the future the flow termination
detection and decission can also be done at the egress. Regarding
motivation on this please see below!
* Allow to optimize the implementation at the interior nodes, in case
that this is needed.

2) In order to make PCN extensible to future scenarios, it should be
possible in the future, (thus not now) to allow flow termination
detection and termination at the egress.
Future possible PCN scenarios are:
* Centralized nodes, collocated with egress nodes can accomplish the
detection and decission for flow termination.
* end-to-edge scenarios, where the end points can be hosts and the edge
can be an aggregator/boundary node.

Now if the detection and decission for flow termination could be done at
the egress, then there are two canditate solutions/schemes that can
fulfil this requirement:

* 3SM

* LC-PCN

In order to be able to select one of them, performance comparisons
between these two schemes are required.

3) Allow solutions for the ECMP routing issue. In order to do that
performance evaluation experiments are needed.

Best regards,
Georgios

---

From: ken carlberg <[email-masked]>
Date: Wed, 12 Mar 2008 11:13:45 -0400

Georgios,

> * Allow to optimize the implementation at the interior nodes, in case

perhaps a different way to view this is the converse of what you are  
asking.  by this I mean, does the architecture draft, as currently  
written,  *prevent* the optimizations you describe?  If not, perhaps  
we  leave the document as is and augment it later with a subsequent  
draft that potentially and optionally optimizes the action of interior  
and border nodes.

-ken