[Iccrg] RE: [tcpm] ECN feedback discussion

Tue Nov 13 13:46:31 GMT 2012

Yes,

ad 2b) an router that implements high density marking changes ECT0 -> ECT1, or ECT1 -> CE

So, a single packet can carry up to two low-density marks simultaneously, for calculating a better estimate of the congestion level at the most congested bottleneck in the path.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Ingemar Johansson S [mailto:ingemar.s.johansson at ericsson.com]
> Sent: Dienstag, 13. November 2012 13:49
> To: Scheffenegger, Richard
> Cc: iccrg at cs.ucl.ac.uk
> Subject: RE: [tcpm] ECN feedback discussion
> 
> 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