Subject: [PCN] Supported congestion notifcation mechanisms of a PCN domain

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 3 Dec 2007 10:42:50 +0100

Phil,

we've had the discussion on the traffic passing a PCN domain with 
the same DSCP earlier. That discussion ended saying there may be 
traffic with the same DSCP as PCN traffic, but not supporting 
PCN mechanisms. Based on this, the following options 
may apply on the traffic sharing the same queue and DSCP:

- not PCN aware, not ECN aware
- not PCN aware, ECN aware
- PCN aware, not ECN aware
- PCN aware, ECN aware

The minimum amount of coding space for PCN to transmit everything
transparently is defined by the single codepoint marking approach. 
That would mean:

- one codepoint indicating no PCN support
- one codepoint indicating PCN support
- one codepoint indicating PCN pre-congestion
- one codepoint indicating ECN support
- one codepoint indicating ECN pre-congestion
- one codepoint indicating ECN and PCN pre-congestion 

No matter what we do, 4 ECN codepoints are insufficient to 
transmit this information. What to do then?

- use a separate DSCP for ECN traffic or for not PCN aware traffic 
  (which may also mean usage of another traffic class)
- apply tunnels from ingress to egress for ECN aware 
  traffic.

Tunnels require another control plane. I don't suggest addition of a 
tunnel protocol to PCN unless one is already operational (like MPLS).

So I prefer separate DSCPs for IP based PCN domains. I'm of course 
happy to have some more discussion (and even happier I would be, if 
there was fast consensus..).

Regards,

Rudiger

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Saturday, December 01, 2007 12:33 AM
To: Geib, Rudiger
Cc: [email-masked]
Subject: Re: [PCN] Re: ECN support in a PCN domain

On 2007-11-29, at 0:02, ext Geib, Ruediger wrote:
> But I agree, the congestion feedback received by an end node is an
> interesting feature and if the WG chairs and the AD feel it to be
> important, we should work on it. The charter says, PCN aware
> application mechanism and flow adaptation are out of scope. Could
> you point out the use case for the legal ECN information received
> by the ingress node, if it is not the latter two?

Most people think of ECN only in conjunction with TCP, because that's  
the most common use. But ECN can be used with any transmission scheme  
that reacts to loss as a signal. For example, a CBR sender might react  
to loss by suspending transmission. This scheme can be improved  
through ECN, so that the sender would suspend transmission when ECN  
marks are received, i.e., before loss occurs. This is why I think that  
allowing end-to-end ECN to happen in conjunction with PCN is important.

(I saw the idea in Robert's recent email of "downgrading" ECN-enabled  
flows into the best-effort class of PCN. I need to think more about  
this, but on first glance this looks like a pretty elegant resolution.  
A flow that is ECN-enabled has basically announced to the network that  
it will react to loss in some way, i.e., probably has some form of  
congestion control. But I need to think about this more.)

Lars

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

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