[Iccrg] RE: [conex] ECN marking over wireless networks

[[e-mail] (Ingemar Johansson S)]

Hi

I can give my input based on LTE simulation work, sofar I see no specific need to convey any extra ECN information about wireless access, also believe that the concept of disclosing CQI stimates outside its context (in this case LTE eNodeB) easily becomes confusing as it then assumes that the endpoints rate adaptation then need to become aware of access technology specifics.

ECN marking algorithms are in my opinion of the same breed as scheduling algorithms, meaning that the implementation is vendor specific. This explains the words in Section 11.6 in 3GPP TS36.300

In addition I don't see any major difference between ECN and packet drops, of course there are differences in the implementation details but there is no reason to convey information as regards to where packets are dropped or what the channel conditions were at the very same timeinstant, why should it then be the case with ECN ?

Regards
Ingemar

> -----Original Message-----
> From: Michael Welzl [mailto:[e-mail]]
> Sent: den 7 juni 2012 11:14
> To: [e-mail]; [e-mail]
> Subject: Re: [conex] ECN marking over wireless networks
>
> Hi,
>
> I've been wanting to write an answer to this for a long time
> but just never got around to it. Sorry!
>
> I see ast least two major problems with suggesting an ECN
> marking method for wireless systems (in fact there are more,
> as you mention in your own
> email):
>
> 1) Fairness. If I get to send at a lower rate, I waste more
> of everyone's resources. My own benefit is also reduced.
> Should I send even less than what the system now allows me,
> to be friendly to everyone, or should I send as much as I
> can? I might be in worse conditions than others; does that
> mean that I should be even worse off? I think the correct
> answer would have to be a function of the impact that my own
> traffic has on the utility that everyone else is getting out
> of the network resources, and the utility that I am getting
> out of them. We can assume a general case of a strictly
> concave function and solve the problem with calculations a la
> proportional fairness... but then again, not all applications
> have such utility functions (e.g. VoIP is different, and
> using e.g. VoIP over WiFi is not at all uncommon). A good
> solution would therefore have to make a local decision that
> is based on knowing which applications are used.
>
> 2) Heterogeneity: wireless systems differ greatly. For
> instance, in [1] we found that, **in total absence of real
> noise**, TCP's throughput across a WLAN can very much depend
> on the chosen rate adaptation mechanisms. Essentially, this
> means that some rate adaptation mechanisms do a bad job at
> trying to detect noise, and mistake collisions for it.
> They then switch to a lower rate when they really shouldn't
> (on a side note, Minstrel, available in MadWifi, seemed to
> always work best). Now, note that in a practical WLAN you
> don't even know which rate adaptation mechanism is chosen by
> the individual hosts participating! Under such conditions,
> how would you make an ECN-marking rule work well for
> everyone? Yes we could design a rule, but that would have to
> depend on the driver and even the configuration of not only
> the AP but all the hosts currently involved.
>
> To conclude: yes I think this is interesting stuff, and worth
> investigating as a research topic. As such it's perfectly
> fine to discuss it at ICCRG (I suggest: on the basis of
> measurements). And maybe (an adaptation of) conex can solve
> problem #1 above - but not problem #2. It is therefore clear
> to me that we cannot make a general recommendation at this
> stage, and I think it's very likely that, even after carrying
> out a lot of research on this, no *general* recommendation
> can ever be made.
>
> Cheers,
> Michael
>
> [1] Naeem Khademi, Michael Welzl, Stein Gjessing:
> "Experimental Evaluation of TCP Performance in Multi-rate
> 802.11 WLANs", accepted for publication, IEEE WoWMoM 2012,
> 25-28 June 2012, San Francisco, California, USA.
>
>
>
> On 5/9/12 10:48 PM, [e-mail] wrote:
> >
> > Hi,
> >
> > There has been some discussion during the IETF 83 in Paris in ICCRG
> > and CONEX WG about relevant ECN marking algorithms over
> wireless networks.
> >
> > Some aspects related to this topic are discussed in this draft:
> >
> http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.
> > pdf, briefly introduced during ICCRG meeting.
> >
> > This email aims at starting some discussion on the mailing lists of
> > ICCRG and CONEX, as requested by the chairs after the discussions
> > during IETF 83.
> >
> > Essentially, the main aspect pointed out during the discussions was
> > that there might benefits in taking into account the radio
> conditions
> > of the mobile terminal for ECN marking over the radio
> segment and for
> > congestion-volume counting. The reason for this is that it requires
> > more radio resources to transmit the same amount of data to
> a terminal
> > in bad radio conditions compared to a terminal in good
> radio conditions.
> >
> > As an introduction to the discussion, it might be useful to mention
> > that different potential /use cases/ for ECN marking involving the
> > mobile terminal could be envisaged:
> >
> > 1.interaction with TCP
> >
> > 2.adapt the coding rate of adaptive application (e.g. adaptive
> > streaming, etc.), as suggested in 3GPP TS 36.300 document
> >
> > 3.stop/delay the non-urgent applications (background tasks in the
> > terminal, etc.)
> >
> > 4.congestion-volume counting (as for Conex related use cases)
> >
> > This list is obviously non-exhaustive, and shows that
> depending on the
> > final utilization of the congestion notification, different
> algorithms
> > for ECN marking over the radio segment might be imagined. The most
> > optimal algorithm certainly depends on the final objective.
> >
> > From the comments received during the discussion, it seems that the
> > first ECN marking algorithm over the radio segment that
> comes to most
> > people's mind is to consider an average queue length
> exceeding a given
> > threshold, as for RED. It should be noted that because the radio
> > segment shares the radio resource among several terminals, one
> > dedicated queue per terminal is in general considered.
> >
> > Therefore, if one would like to apply RED over a wireless
> segment, it
> > should be clarified whether it would be applied
> independently on each
> > dedicated queue per terminal (n instances of RED considered for the
> > radio segment), or on the sum of all the dedicated queues (1 single
> > instance of RED considered for the radio segment). This
> would lead to
> > two different ECN marking /criteria/:
> >
> > 1.RED based on the individual queue of each terminal
> >
> > 2.RED based on a single shared queue between all the terminals
> >
> > Several remarks were raised during the presentation of the draft in
> > ICCRG and the discussion in CONEX:
> >
> > -On the interactions with TCP (use case #1 listed above), it was
> > mentioned that TCP works on a longer timescale relative to the
> > wireless channel. In other words: the radio conditions may
> vary more
> > quickly than TCP reactions. This is correct, however, it should be
> > mentioned that the objective of ECN marking over the radio
> segment is
> > not to replace the existing radio schedulers, which already
> provide a
> > suitable control loop over these shorter time scales. As an
> example,
> > the very common Proportional Fair (PF) algorithm aims at addressing
> > exactly this point, by trying to optimize the allocation of radio
> > resources (the terminals in good instantaneous radio conditions are
> > favored compared to the others, as to optimize the cell capacity,
> > while certain fairness is ensured in the longer term by taking into
> > account also the averaged throughputs delivered to the terminals).
> >
> > -Still regarding the interactions with TCP (use case #1
> listed above),
> > assume now that a PF algorithm is used to control the allocation of
> > radio resources. It was mentioned also that if it is
> assumed that ECN
> > marking is done according to the individual queue of each terminal
> > (criteria #1 listed above), then a terminal in bad radio conditions
> > will already experience ECN marking more often without the need to
> > weight the probability of the ECN marking with the radio
> conditions of
> > the terminal. This is due to the fact that PF provides higher
> > throughput to terminals in good averaged radio conditions
> than in bad
> > averaged radio conditions. Actually, the amount of ECN marking will
> > depend in this case whether the throughput required to transmit the
> > data to a particular terminal is lower than the throughput
> provided to
> > this terminal by PF; if not, then no ECN marking should happen for
> > this terminal in these conditions (even during congested periods
> > actually).
> >
> > -Based on this discussion, it seems to me that the
> interaction of ECN
> > marking with TCP should not be analyzed in terms of
> benefits it brings
> > to control the allocation of resources over the radio
> segment, which
> > is already under the control of the radio scheduler. It seems that
> > this second control loop provided by ECN marking
> interacting with TCP
> > would rather aim at indicating when the traffic rate of a terminal
> > exceeds the throughput provided by PF to this terminal,
> which could be
> > useful for use case #2 (coding rate adaptation). Basically, it is
> > expected that this second control loop would try to "align"
> with the
> > throughput provided by the first one (keeping in mind that
> PF provides
> > throughputs varying with time).
> >
> > -The same example but now with the ECN marking criteria #2
> instead of
> > #1 raises however issues. Indeed, in case the throughput
> required to
> > transmit the data to one particular terminal is lower than the
> > throughput provided to this terminal, this will lead to ECN marking
> > for all the terminals, even the ones below the PF
> throughput, which is
> > a situation that should be avoided when interaction with TCP is
> > desirable. Excessive traffic consumption on one terminal should not
> > impact the others (i.e. should not lead to the generation of ECN
> > marking for the others). Definitely, the criteria #1 does
> not seem a
> > good idea when interaction with TCP is desired.
> >
> > -Considering the use case #3 depicted earlier now, it
> should be noted
> > however that the previous situation with PF + ECN marking based on
> > individual queues (criteria #1) has some limitation.
> Indeed, in case
> > of radio congestion (assume here that radio congestion
> means that all
> > the radio resources are used and are not enough to transmit all the
> > data to be transmitted to all the terminals - a more accurate
> > definition might be found), some of the terminals may not
> received ECN
> > marking, as indicated before (in case they require less
> than what PF
> > can provide to them). Perhaps some of the data transmitted to these
> > non-notified terminals are not so critical and might be
> delayed, as to
> > free resources to the other users with more important traffic to be
> > exchanged. The depicted situation does not provide incentives to do
> > this, because ECN marking only applies to some users. It is
> the reason
> > why it might be interesting to consider other ECN marking
> algorithms
> > (which might not aim at interacting necessarily with TCP;
> BTW not all
> > the applications are running over TCP), as to inform about the
> > congestion situation. The idea is to say to the end user: "Hey! The
> > system starts being full, the PF algorithm will still
> provide you with
> > some network resources, but if some of your data can be delayed,
> > please do so!" Of course, this kind of approach might be
> coupled with
> > congestion-volume counting / CONEX use cases, to provide incentives.
> >
> > -Let's take a practical example to illustrate (note sure it is the
> > best one, but it is the one that comes to my mind...): you
> need to go to
> > some administration to collect some administrative document
> - say, a
> > voting card to elect your new president. There is already a long
> > queue, but you could pass with a "certain priority" because
> what you
> > need to do is faster than what other people have to do. However, if
> > you collect your document, you consume resources of the system that
> > will not be available to the others during this time - the
> person in
> > front of you will be busy giving you your document. And
> what you need
> > to do is not urgent - the election is not tomorrow, you
> will have time
> > to come back later. Perhaps you would like to be fair with
> the other
> > people having more urgent things to do and waiting in the
> queue, and
> > you will not wait and instead come back later? And perhaps a signal
> > indicating the congestion might be useful (it is probably
> good to know
> > if the queue is long or not, rather than waiting without
> information).
> >
> > -Considering the use case #4 depicted earlier now on
> congestion-volume
> > counting: it seems logical to me that the count would take into
> > account the real network resource usage rather than simply
> the number
> > of bits transmitted. This would provide again incentives to
> users in
> > bad radio conditions to delay non-urgent network usage.
> Moreover, an
> > interesting question which should be raised would be to define what
> > corresponds to a "congested period" for the radio segment:
> is it only
> > when the terminal exceeds its PF rate, or should a
> congestion period
> > be considered when the system starts being full/is full? This might
> > trigger different ECN marking algorithms on the wireless segment.
> >
> > I had noted two other comments from the discussions in IETF 83:
> >
> > -TCP middlebox accelerating TCP window growth: some comment
> was made
> > on the mic, however I am not sure that I understood what
> this device
> > is supposed to do; would anyone of you have some reference on this?
> >
> > -Retransmission over the radio segment: should it be taken into
> > account as well for congestion-volume counting? It would
> mean that a
> > lost packet that is retransmitted by the low layers should
> be counted
> > twice? (after all, if it was retransmitted by TCP, it would
> have been
> > counted twice as well, right?)
> >
> > Feedback on this discussion is welcomed. Thanks in advance.
> >
> > Cheers,
> >
> > *S?bastien JOBERT*
> > Orange Expert "Future Networks", network synchronization and QoS in
> > mobile networks *Orange Labs, Networks & Carriers - France Telecom
> > R&D* [e-mail]
> > <mailto:[e-mail]>
> >
> >
> >
> > _______________________________________________
> > conex mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/conex
>
>
>