[Iccrg] ECN feedback discussion

[Ingemar Johansson S]

Hi

A few comments on an interesting topic.
 
QoS dependent ECN marking: 
I believe the idea to use different ECN marking strategies depending on QoS (or perhaps QCI=QoS class identifier in LTE) has been discussed earlier. 
I am however pretty much in favor of having one strategy regardless of QoS, mainly because of the relative simplicity compared to a special ECN treatment depending on QCI. This may in the end mean that services with a higher QoS will have a higher ECN marking rate  than services with a lower QoS but I don't really see a problem with that and long as it is allowed by operator policies. Also it blends well with the "weighted farness" ideas. In fact ConEx (if it flies) is a good policing framework for this in the sense that services with higher QoS can cause a higher congestion volume.

High density vs Low Density ECN marking:
I really like the idea as it can for instance enable a smoother rate adaptation for e.g video because of the higher number of congestion signals.
Had a look into 3GPP TS36.300, no distinction is made between ECT(0) and ECT(1) there. This means that additional specification is needed to specify that ECT(1) means smomething like "apply high density ECN marking if implemented". When 3GPP TS 26.114 was specified it was explicitly mentioned that ECT(0) should be used, the idea behind was that at some stage there may pop up some interesting use for ECT(1) so it is then best to avoid messing with it. Low/High density ECN is a good cantidate.

/Ingemar
=================================
Ingemar Johansson  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson at ericsson.com
www.ericsson.com

"However beautiful the strategy, 
 you should occasionally look at the results" 
        Sir Winston Churchill
=================================

----------------------------------------------------------------------

Message: 1
Date: Sat, 10 Nov 2012 16:35:12 +0000
From: "Scheffenegger, Richard" <rs at netapp.com>
Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
To: Michael Welzl <michawe at ifi.uio.no>
Cc: "iccrg at cs.ucl.ac.uk list" <iccrg at cs.ucl.ac.uk>
Message-ID: <CBF80A27-8455-476F-8E6E-50E080EF6423 at netapp.com>
Content-Type: text/plain; charset="utf-8"

That would be my stance too...

Imho, part of why ecn has failed to get traction was/is the complex and nondeterministic way in which the end systems and the network in between are supposed to run a distributed control loop that should keep congestion (standing buffer queues/buffer overflows) at bay.

Imho, dctcp has a very good point in keeping the control loop entirely in the end systems and have a very simple, straight forward and deterministic marking scheme in the network...

I think we need first and foremost a signaling scheme that should lend itself to the most broad applications.

A counter (of some sort, however implemented) would be a huge step forward.

I'm also wondering, if there is information to be had off the exact "pattern" (in the time domain) from CE (or ECT1 too) marks...

I.e. Is a sudden jump from no marks to all marks and then a slow drop of marking probability - all in one RTT - different from a slow rise in markin probabiliy up to 100%, followed by a sudden drop to no marks? With the total number of marks in one RTT equal in both cases? Can anyone think that such a 2nd order signal might be useful, or does anyone know of research into such aspects?


Best regards,
   Richard

Von meinem iPhone gesendet

Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <michawe at ifi.uio.no>:

> Hi,
> 
> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to embed QoS in it isn't exactly going to improve the probability of success IMO.
> 
> Cheers,
> Michael
> 
> 
> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
> 
>> I think updating the behaviour of ECN would be a great idea -
>> 
>> We could have different behaviours for different types of 
>> communication - for e.g.
>> 
>> (1) we could be less aggressive to emergency communications
>> (2) We could be more aggressive to scavenger type traffic
>> (3) We do the normal ecn behaviour inbetween
>> 
>> So probably we-ve got to map QoS behaviour to ECN I guess..
>> 
>> Arjuna
>> 
>> On 9 November 2012 04:50,  <iccrg-request at cs.ucl.ac.uk> wrote:
>>> Send Iccrg mailing list submissions to
>>>       iccrg at cs.ucl.ac.uk
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>       http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>> or, via email, send a message with subject or body 'help' to
>>>       iccrg-request at cs.ucl.ac.uk
>>> 
>>> You can reach the person managing the list at
>>>       iccrg-owner at cs.ucl.ac.uk
>>> 
>>> When replying, please edit your Subject line so it is more specific 
>>> than "Re: Contents of Iccrg digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>>  1. Re: [tcpm] ECN feedback discussion (Michael Welzl)  2. Re: New 
>>> co-chair (Eggert, Lars)  3. Re: [tcpm] ECN feedback discussion 
>>> (Yuchung Cheng)  4. Re: [tcpm] ECN feedback discussion (Michael 
>>> Welzl)  5. Re: Re: [tcpm] ECN feedback discussion (Mikael 
>>> Abrahamsson)
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> --
>>>