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

From: Magnus Westerlund <[email-masked]>
Date: Sat, 01 Dec 2007 20:22:11 +0100

Lars Eggert skrev:
> (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.)
> 

Well, that assumes that you never want to run ECN on something that uses
PCN. I think that assumption is wrong. A use case for PCN is within a
cellular core network. Where you use PCN to ensure that your voice
traffic get the best possible QoS through the core network. Even in such
a situation you have wireless links that you can't provide any
guarantees for and congestion may arise. To my knowledge ECN isn't used
yet but could be.

I wished we where on clearer ground when it comes to real-time ECN usage.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 01 Dec 2007 21:07:39 +0100

Geib, Ruediger skrev:
> 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?

I wouldn't express things like this. We ADs are only trying to ensure
that PCN has minimal implications on defined and deployed functionality.
That include ECN that is deployed and somewhat used. But so far the
usage we see is TCP. However, the ECN spec is quite clear that it
applies to any protocol. But there is no defined feedback channel for
ECN when using UDP. But remember that DCCP do have ECN support.

That is why the sentence about ECN exist in the PCN charter. PCN
shouldn't prevent ECN from being used down the road, unless we are very
certain it is the right way to go. And this requires more than PCN
consensus.

Cheers

Magnus Westerlund

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 2 Dec 2007 13:10:12 -0000

hi, 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Lars Eggert skrev:
> > 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 
> Well, that assumes that you never want to run ECN on 
> something that uses PCN. I think that assumption is wrong. A 
> use case for PCN is within a cellular core network. Where you 
> use PCN to ensure that your voice traffic get the best 
> possible QoS through the core network. Even in such a 
> situation you have wireless links that you can't provide any 
> guarantees for and congestion may arise. To my knowledge ECN 
> isn't used yet but could be.
> 

To be clear, I am quite happy with there being use cases for ECN
being used with traffic that also goes through an admission control
process for some sort of capacity reservation (indeed, I can think
of some additional ones). I think the only reason ECN concepts are
so closely associated with TCP is the relative lack of other sorts
of traffic in the wild until quite recently.

So, the point is not to claim that ECN and PCN should never be used 
together. Rather, it's to suggest that if it's the case that even *if*
it's impossible to find a PCN solution which both
- is simple enough to get initial deployment, and
- avoids trampling the ECN bits
then there is still a case for a simple PCN solution which only
helps non-ECN traffic if it also does no harm to ECN traffic.
PCN will be better than nothing for some traffic, and not worse
than the status quo for everything else. A PCN solution which is 
better than nothing for all traffic could be a subsequent evolution.

(Really I guess this is all a discussion about whether there are
simple, feasible solutions which 'cleanly integrate with ECN' in 
the language of the charter.)

robert h.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 3 Dec 2007 09:04:21 +0100

Magnus,

your response sounds to me like

- off PCN charter: definition of end system behaviour once 
  ECN pre-congestion indication or feedback is received.

- on PCN charter: transport of ECN information to an 
  end system.

I'd like to be clear on what's expected form the PCN WG.

Regards,

Rudiger

|-----Original Message-----
|From: Magnus Westerlund [mailto:[email-masked]]
|Sent: Saturday, December 01, 2007 9:08 PM
|To: Geib, Rüdiger
|Cc: [email-masked]
|Subject: Re: [PCN] Re: ECN support in a PCN domain
|
|
|Geib, Ruediger skrev:
|> 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?
|
|I wouldn't express things like this. We ADs are only trying to ensure
|that PCN has minimal implications on defined and deployed 
|functionality.
|That include ECN that is deployed and somewhat used. But so far the
|usage we see is TCP. However, the ECN spec is quite clear that it
|applies to any protocol. But there is no defined feedback channel for
|ECN when using UDP. But remember that DCCP do have ECN support.
|
|That is why the sentence about ECN exist in the PCN charter. PCN
|shouldn't prevent ECN from being used down the road, unless we are very
|certain it is the right way to go. And this requires more than PCN
|consensus.
|
|Cheers
|
|Magnus Westerlund
|
|IETF Transport Area Director & TSVWG Chair
|----------------------------------------------------------------------
|Multimedia Technologies, Ericsson Research EAB/TVM
|----------------------------------------------------------------------
|Ericsson AB                | Phone +46 8 4048287
|Torshamsgatan 23           | Fax   +46 8 7575550
|S-164 80 Stockholm, Sweden | mailto: [email-masked]
|----------------------------------------------------------------------
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 3 Dec 2007 20:52:04 +0100

Hi

Because of the discussion of the possible use of ECN for other things
than TCP, below a collection of refrences with potential use cases that
perhaps highlights the benefits of being able to keep ECN transparent
end2end even through a PCN domain without the need to downgrade to best
effort or something similar. 

Regards
Ingemar
=========================
Thesis reports:
Fredrik Hultin
"Congestion notification and rate-adaptation for real-time services in
All-IP radio networks" 
http://epubl.ltu.se/1402-1617/2007/244/LTU-EX-07244-SE.pdf
Sarker, A.N.M. Zaheduzzaman
"A study on adaptive real time video over LTE "
http://epubl.ltu.se/1653-0187/2007/064/LTU-PB-EX-07064-SE.pdf
The two thesis reports was written in parallel where the first dealt
with the network and the second dealt with the application.

There is also ongoing some work regarding this in 3GPP, below a
collection of documents that may be of interest.  
S4-070563:Real-time adaptive communication services in LTE
 http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_45/Docs/S4-070563.zip
Mentions only the word "congestion warning" but refers to... 
S2-073328:Rate adaptation with "MBR>GBR bearers"
 
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_59_Helsinki/Docs/S2-073328
.zip
Describes how ECN can be used for MBR<->GBR bearers

Additionally:
S2-075184:
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518
4.zip
S2-075185:
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518
5.zip
Latest documents in 3GPP RAN2 that deals with the use of ECN
=========================

> From: Robert Hancock [mailto:[email-masked]] 
> Sent: den 2 december 2007 05:10
> To: Magnus Westerlund; 'Lars Eggert'
> Cc: [email-masked]
> Subject: RE: [PCN] Re: ECN support in a PCN domain
> 
> hi, 
> 
> > Well, that assumes that you never want to run ECN on something that 
> > uses PCN. I think that assumption is wrong. A use case for PCN is 
> > within a cellular core network. Where you use PCN to ensure 
> that your 
> > voice traffic get the best possible QoS through the core 
> network. Even 
> > in such a situation you have wireless links that you can't 
> provide any 
> > guarantees for and congestion may arise. To my knowledge ECN isn't 
> > used yet but could be.
> > 
> To be clear, I am quite happy with there being use cases for 
> ECN being used with traffic that also goes through an 
> admission control process for some sort of capacity 
> reservation (indeed, I can think of some additional ones). I 
> think the only reason ECN concepts are so closely associated 
> with TCP is the relative lack of other sorts of traffic in 
> the wild until quite recently.
> 
> So, the point is not to claim that ECN and PCN should never 
> be used together. Rather, it's to suggest that if it's the 
> case that even *if* it's impossible to find a PCN solution which both
> then there is still a case for a simple PCN solution which 
> only helps non-ECN traffic if it also does no harm to ECN traffic.
> PCN will be better than nothing for some traffic, and not 
> worse than the status quo for everything else. A PCN solution 
> which is better than nothing for all traffic could be a 
> subsequent evolution.
> 
> (Really I guess this is all a discussion about whether there 
> are simple, feasible solutions which 'cleanly integrate with 
> ECN' in the language of the charter.)
> 
> robert h.
> 
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Dec 2007 17:51:22 -0800

>   ECN pre-congestion indication or feedback is received.

Did you mean ECN congestion indication? I think one can't only talk
about congestion indication, but also the ECN enabled. But independent
of either you are correct that it is true that it is of charter to
define end-system response, beyond session admission or termination.

> - on PCN charter: transport of ECN information to an 

In the sense that the information flow for ECN is capable of making it
across a PCN domain.

Cheers

Magnus Westerlund

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 13 Dec 2007 12:35:23 +0000

Ingemar,

I've now read the 3GPP refs below. I just wanted to list the translations 
of the abbreviations I had to look up, both as a service to anyone else 
trying to read the 3GPP docs who doesn't come from a 3GPP background :) and 
to ask you to check I'm got them correct...

GBR guaranteed bit rate
MBR maximum bit rate
AMBR aggregate maximum bit rate
OBR offered bit rate

AMR adaptive multirate
PSS packet-switched streaming service

EPS evolved packet service (= system architecture evolution (SAE))
EPC evolved packet core
MTSI multimedia telephony service for IMS (IP Multimedia Subsystem)

eNB enhanced node B (base station)

FFS for further/future study

---
Sorry the list isn't exhaustive - there were more that I haven't listed 
'cos I knew them already.

Bob

>effort or something similar.

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 13 Dec 2007 13:16:28 +0000

Ingemar,

You're right that we must ensure that standards activity understands the 
research that has been done in a field before inventing solutions. As your 
MSc students found, there is little work on using ECN with CDMA or 802.11 
specifically.

But they missed this collection of work that goes into exactly what might 
be congested on the up-link and down-link and how resource sharing of the 
radio link should interact with e2e congestion control (using ECN):
<http://www.ics.forth.gr/netlab/future_wireless.html>
(the Mobicom paper is probably most relevant)

There's also Mung Chang et al's work on cross-layer optimisation, which 
sets the architectural scene very well. It requires some interpretation for 
a standards audience:
<http://www.princeton.edu/~chiangm/layering.pdf>

I should add that none of these are specifically about multi-rate adaptive 
apps. I've also not listed any refs to the considerable body of work on 
using ECN to distinguish transmission losses from congestion, which is a 
more specific subject-area than we need here.

Bob

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 13 Dec 2007 14:48:49 +0100

Hi

I can verify that the abbreviations below are correct.

Ingemar

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 13 december 2007 13:35
> To: Ingemar Johansson S
> Cc: [email-masked]
> I've now read the 3GPP refs below. I just wanted to list the 
> translations of the abbreviations I had to look up, both as a 
> service to anyone else trying to read the 3GPP docs who 
> doesn't come from a 3GPP background :) and to ask you to 
> check I'm got them correct...
> 
> GBR guaranteed bit rate
> MBR maximum bit rate
> EPS evolved packet service (= system architecture evolution 
> (SAE)) EPC evolved packet core MTSI multimedia telephony 
> service for IMS (IP Multimedia Subsystem)
> 
> Sorry the list isn't exhaustive - there were more that I 
> haven't listed 'cos I knew them already.
> 
> 
> 
> Bob
> 
> something that
> > > > I wished we where on clearer ground when it comes to 
> real-time ECN
> > > > usage.
> > >