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

From: Michael Menth <[email-masked]>
Date: Sat, 21 Jun 2008 18:23:18 +0200

Hi Ingemar,

what is the message of this draft?

a) Don't reset the ECN field to not-ECT for flows crossing a PCN
domain.

b) Provide PCN marking from within the PCN domain in terms of
CE-marks to the end systems. If this is the case, what kind of
feedback is useful:
 i)  marking all packets of a flow with CE (exhaustive marking)
 ii) or just a fraction of them? (excess marking)

Regards,

    Michael

Ingemar Johansson S wrote:
> 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
>   

-- 
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: Mon, 23 Jun 2008 12:57:09 +0200

Hi

Answers below.

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]] 
> Sent: den 21 juni 2008 18:23
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [PCN] Usecases and Benefits of end to end ECN 
> support in PCN Domains
> 
>  Hi Ingemar,
> 
> a) Don't reset the ECN field to not-ECT for flows crossing a 
> PCN domain.
Correct
 
> CE-marks to the end systems. If this is the case, what kind 
> of feedback is useful:
It is not necessary if we only consider congestion that occurs outside PCN domains like in case 1) below. If however we discuss cases like 2) or 3) below...
Difficult to answer to this question (i or ii), my guess is that the client should be liberal in what ECN-CE pattern it receives. A coarse method is that the media receiver requests a reduction of e.g the video bitrate by 50% if more than N ECN-CE marked packets are received in a given short timeframe. This method would be fairly robust to both alternatives (i or ii) above.

Originally the main focus was on maintaining e2e ECN semantics across PCN domains. Under normal circumstances one could argue that with proper resource reservation and the use of e.g PCN there should not be any specific need to maintain e2e ECN semantics for for e.g EF-flows as there will (in theory) not be any congestion experienced for these flows. 
There are however at least three scenarios where e2e ECN semantics are useful.
1) Wireless transmission: Due to issues like shadowing, hot spots et.c. It is not always possible to maintain a given QoS. The use of ECN in both wireless up and downlink would provide with a possibility for a quick response to congestion.
2) Flash crowds: As I understand this can become an issue within PCN domains. A means to tamper this would be that either the ingress or egress nodes ECN mark flows. The flows that comply within a given time frame are treated gently while non-compliant flows are treated worse.
3) Emergency services: There could be a desire to elevate priority for eg. emergency services. Ecn marking can here serve as a mechanism to free network resources without the need to terminate flows. The similar policing as in 2) could be used here.

/Ingemar

> > The ECN-PCN usecases draft has been updated. The main 
> addition is the section 3.5 suggested by Ken Carlberg.
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206