Subject: Re: [PCN] Re: ECN support in a PCN domain

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 29 Nov 2007 09:02:27 +0100

Lars,

my own concern about the issue was weaker (behaviour of an ingress node 
in the case of a possible misuse of PCN colouring from an external 
interface). 

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?

Regards,

Rudiger

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Wednesday, November 28, 2007 7:12 PM
To: ext [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Re: ECN support in a PCN domain

On 2007-11-28, at 19:49, ext [email-masked] wrote:
> there was quite a lot of discussion (without resolution) whether it's
> reasonable for a flow that uses PCN adm ctrl to also want e2e ECN for
> rate adaptation (discussion both in terms of whether a flow would
> actually ever want this, and how well the PCN mechanism would work if
> flows were adapting like this).
> this was resolved by saying that the support of e2e ecn is out of  
> scope
> of initial charter of pcn.

Lars wrote:

Huh? The charter says:

   All PCN mechanisms, including transport and encoding
   of (pre-congestion) information, are required to cleanly integrate
   with existing architectures and protocols such as DiffServ and ECN.

"Cleanly integrate" doesn't mean "out of scope", it means "must work  
together with".

TSVWG published RFC4774 to describe which alternate uses of the ECN  
bits are OK; the PCN mechanisms are supposed to instantiate such an  
accepted alternate use.

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 30 Nov 2007 15:33:26 -0800

> 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