[Iccrg] RE: [tcpm] ECN feedback discussion

Tue Nov 13 12:49:03 GMT 2012

Hi

Must admit that I a bit lost here. 
The idea is that 
1) the sender sets ect0
2a) a congested router sets ce if it implements low density marking
2b) alternatively a router that implements high density marking sets packets to ect1 or ce. 

Right or ?

/Ingemar

-----Original Message-----
From: Scheffenegger, Richard [mailto:rs at netapp.com] 
Sent: den 12 november 2012 11:04
To: Ingemar Johansson S
Cc: iccrg at cs.ucl.ac.uk; tcpm at ietf.org
Subject: Re: [tcpm] ECN feedback discussion

Alternative to using ect1 by the sender (allowing high density ecn marking), what about the sender continuing to use ect0, but high density ecn marking by routers changing that from ect0 to ect1 and ect1 to ce (or ect0 directl to ce on very high load)?

Some papers claim that having an counter to allow multiple routers marking the same packet enables better signal for cc...

also, legacy receivers would only react to ce as usual and not fine grained...

Best regards, richard

Von meinem iPhone gesendet

Am 12.11.2012 um 09:02 schrieb "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>:

> 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)
>>>> 
>>>> 
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm