Subject: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 26 May 2008 09:56:35 +0200

Hi

The ECN-PCN usecases draft has been updated. The main addition is the section 3.5 suggested by Ken Carlberg.
http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt

Comments are welcome
/Ingemar
******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)8 4043042 
ECN: 850-43042 
ECC: 850-43074 
Mobile: +46 (0)730 783289 
******************************************* 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Mayutan A." <[email-masked]>
Date: Tue, 27 May 2008 08:56:22 +0200

Hi
My two cents:

Since PCN is defined for inelastic traffic, when an adaptive application is
denied admission, it can adapt its sending rate and try again. This is
similar to the application
receiving a congestion marked packet and therefore lowering its rate (for
e.g a video streaming application lowering the quality or the video
streamed). Eventually the PCN aims at end-to-end deployment and thus favours
adaptive applications.

Mayutan

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Tue, 27 May 2008 09:03:00 +0200

Hi Mayutan,

it's similar, but not the same. While ECN allows rate adaptation for 
flows in progress, your alternative allows it only for flows that are 
not yet permitted. An end-to-end deployment of PCN is not within the 
current charter.

Regards,

    Michael

Mayutan A. wrote:
> Hi
> My two cents:
>
> Since PCN is defined for inelastic traffic, when an adaptive 
> application is denied admission, it can adapt its sending rate and try 
> again. This is similar to the application
> receiving a congestion marked packet and therefore lowering its rate 
> (for e.g a video streaming application lowering the quality or the 
> video streamed). Eventually the PCN aims at end-to-end deployment and 
> thus favours adaptive applications. 
>
> Mayutan
>
> On Mon, May 26, 2008 at 9:56 AM, Ingemar Johansson S 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi
>
>     The ECN-PCN usecases draft has been updated. The main addition is
>     the section 3.5 suggested by Ken Carlberg.
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

-- 
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: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 27 May 2008 10:30:33 +0200

Hi

Agree with Michael, the use case below sounds in my opinion like something that is done during the session setup and with interaction between the client and the admission control scheme, I don't believe that ECN can be used for this purpose as there is no flow running.

/Ingemar

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]] 
> Sent: den 27 maj 2008 09:03
> To: Mayutan A.
> Cc: Ingemar Johansson S; [email-masked]
> Subject: Re: [PCN] Usecases and Benefits of end to end ECN 
> support in PCN Domains
> 
> Hi Mayutan,
> 
> it's similar, but not the same. While ECN allows rate 
> adaptation for flows in progress, your alternative allows it 
> only for flows that are not yet permitted. An end-to-end 
> deployment of PCN is not within the current charter.
> 
> Regards,
> 
>     Michael
> 
> Mayutan A. wrote:
> > Hi
> > My two cents:
> >
> > again. This is similar to the application receiving a congestion 
> > marked packet and therefore lowering its rate (for e.g a video 
> > streaming application lowering the quality or the video streamed). 
> > Eventually the PCN aims at end-to-end deployment and thus favours 
> > adaptive applications.
> >
> > Mayutan
> >
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: "Mayutan A." <[email-masked]>
Date: Tue, 27 May 2008 13:48:31 +0200

Hi,

Thanks Michael and Ingemar, I get the difference now. I was talking about
UDP applications trying to get some acceptable QoS during connection setup,
whereas the draft proposal discusses about applications that can adapt on
the fly depending on the congestion in the network. The point I was making
is that in a PCN domain, once an application flow is admitted, the domain
ensures that it provides all accepted flows with a guaranteed  QoS as long
as there aren't any unexpected node/link failures.

But I agree that during the initial stages when not many domains are PCN
capable, the adaptive applications can play a part in adapting its rate on
receiving ECN marked packets and adjusting accordingly.

Cheers,
Mayutan

On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S <
[email-masked]> wrote:

> Hi
>
> Agree with Michael, the use case below sounds in my opinion like something
> that is done during the session setup and with interaction between the
> client and the admission control scheme, I don't believe that ECN can be
> used for this purpose as there is no flow running.
>
> /Ingemar
>

---

From: "Nguyen, An P" <[email-masked]>
Date: Tue, 27 May 2008 11:04:21 -0400

Mayutan,

Just a question for you: Would accepted flows with a guaranteed QoS get rerouted in a PCN domain if there is a node/link failure?

Thanks,

An

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mayutan A.
Sent: Tuesday, May 27, 2008 7:49 AM
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCNDomains

Hi, 

Thanks Michael and Ingemar, I get the difference now. I was talking about UDP applications trying to get some acceptable QoS during connection setup, whereas the draft proposal discusses about applications that can adapt on the fly depending on the congestion in the network. The point I was making is that in a PCN domain, once an application flow is admitted, the domain ensures that it provides all accepted flows with a guaranteed  QoS as long as there aren't any unexpected node/link failures. 

But I agree that during the initial stages when not many domains are PCN capable, the adaptive applications can play a part in adapting its rate on receiving ECN marked packets and adjusting accordingly.

Cheers,
Mayutan 

On Tue, May 27, 2008 at 10:30 AM, Ingemar Johansson S <[email-masked]> wrote:

Hi

/Ingemar

---

From: "Mayutan A." <[email-masked]>
Date: Tue, 27 May 2008 17:34:02 +0200

Hi,

See inline:

On Tue, May 27, 2008 at 5:04 PM, Nguyen, An P <[email-masked]> wrote:

>  Mayutan,
>
>
>
> Just a question for you: Would accepted flows with a guaranteed QoS get
> rerouted in a PCN domain if there is a node/link failure?
>
> I have already mentioned that in my previous mail

"The point I was making is that in a PCN domain, once an application flow is
admitted, the domain ensures that it provides all accepted flows with a
guaranteed  QoS as long as there aren't any unexpected node/link failures. "

Yes, when there is a route failure, flows get rerouted in the PCN domain and
Flow termination comes into play. In this case, an *adaptive* application
might be able to prevent its flow getting terminated.

Anyways, would copying the original ECN fields into an IP option header
field at the Ingress and then recopying it back into the ECN fields by the
egress solve this problem. Or would encapsulation /decapsulation solve this.
Just brain-storming here.

Thanks,
Mayutan

>
> Thanks,
>
>
>
> An
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Mayutan
> A.
> *Sent:* Tuesday, May 27, 2008 7:49 AM
> *To:* Ingemar Johansson S
> *Cc:* [email-masked]
>
> *Subject:* Re: [PCN] Usecases and Benefits of end to end ECN support in
> PCNDomains
>
>
>
> Hi,
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 28 May 2008 08:25:37 +0200

Hi Mayutan,
 
the general statement that termination starts after rerouting isn't automatically true. It depends on
 
- how your network is engineered / provisioned
- the PCN traffic levels of the failed link(s) and the link(s) to which traffic is rerouted
 
To me, PCN definitely isn't meant to be operated in non engineered networks. I expect somewhat 
tough SLAs on the probability of facing an admission stop indication (below 0.01%?). The SLA on the 
occurance of termination will be tougher.
 
I expect termination marks within a PCN domain under commercial operational conditions to be a 
possible, but rare event.
 
Regards,
 
Rudiger

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Mayutan A.
	Sent: Tuesday, May 27, 2008 5:34 PM
	To: Nguyen, An P
	Cc: [email-masked]
	Subject: Re: [PCN] Usecases and Benefits of end to end ECN support inPCNDomains

	Hi, 
	
	See inline:

		Mayutan,

	
	"The point I was making is that in a PCN domain, once an application flow is admitted, the domain ensures that it provides all accepted flows with a guaranteed  QoS as long as there aren't any unexpected node/link failures. "
	
	Yes, when there is a route failure, flows get rerouted in the PCN domain and Flow termination comes into play. In this case, an adaptive application might be able to prevent its flow getting terminated.
	
	Anyways, would copying the original ECN fields into an IP option header field at the Ingress and then recopying it back into the ECN fields by the egress solve this problem. Or would encapsulation /decapsulation solve this. Just brain-storming here. 
	
	Thanks,
	Mayutan  

		Thanks,

		An

		 

		Hi, 

		
		Cheers,
		Mayutan 

		Hi

		/Ingemar

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 28 May 2008 13:09:23 +0200

Hi
 
I belive that one possible use case (as mentioned in the draft) would be to cope with flash-crowds or to be able to elevate emergency services and perhaps also to be able to cope with link failures in a graceful way. For this purpose it would be possible to ECN mark flows (or aggregates). 
Now, depending on implementaion most applications will preferrably respond to ECN marks with e.g a reduced bitrate (within rougly a roundtrip time). There is however a risk that applications does not respond to ECN marks, for this pupose the ingress or egress nodes with meter/marker/shaper possibilities could have the possibility to e.g demote flows that does not follow the rules.
 
How ECN are to be able to be maintained thorugh a PCN domain is currently an open question. The options I see are either tunneling or use of extra DSCP codepoints.
 
/Ingemar

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Mayutan A.
	Sent: den 27 maj 2008 17:34
	To: Nguyen, An P
	Cc: [email-masked]
	Subject: Re: [PCN] Usecases and Benefits of end to end ECN support inPCNDomains

	Hi, 
	
	See inline:

		Mayutan,

	

	
	Thanks,
	Mayutan  

		Thanks,

		An

		 

		Hi, 

		
		Cheers,
		Mayutan 

		Hi

		/Ingemar