[conex] ECN marking over wireless networks

[<[e-mail]>]

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]>