[Iccrg] Re: [conex] ECN marking over wireless networks
Michael Welzl
michawe at ifi.uio.no
Thu Jun 7 10:14:29 BST 2012
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, sebastien.jobert at orange.com 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*
> sebastien.jobert at orange.com <mailto:sebastien.jobert at orange-ftgroup.com>
>
>
>
> _______________________________________________
> conex mailing list
> conex at ietf.org
> https://www.ietf.org/mailman/listinfo/conex
More information about the Iccrg
mailing list