Subject: [Iccrg] Re: draft-fairhurst-tcpm-newcwv-03 - Status?
From: [email-masked] (Scharf, Michael (Michael))
Date: Fri Jun 22 18:50:09 2012

> Since Gorry is saying that they'd love more comments, can I 
> ask for volunteers to do a thorough review? For previous 
> proposals of changes to TCP's congestion control, we had 2-3 
> such reviews.

Just wondering: Is there experimental data beyond http://www.ietf.org/proceedings/80/slides/iccrg-2.pdf? For instance, data regarding benefits and risks compared to using CWV with IW10?

The IW10 draft also allows a restart-window of 10 MSS, with a MAY. This might reduce the performance "penalty" of CWV.

Michael

From: [email-masked] (Michael Welzl)
Date: Fri Jun 22 08:43:48 2012
Subject: [Iccrg] Fwd: draft-fairhurst-tcpm-newcwv-03 - Status?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

For context, here is the original email that my previous message 
answered. I now noticed that I was the only one who got it (I guess?) 
because of a wrong email address for ICCRG.

-------- Original Message --------
Subject: 	draft-fairhurst-tcpm-newcwv-03 - Status?
Date: 	Thu, 21 Jun 2012 15:43:47 +0100
From: 	Gorry Fairhurst <[email-masked]>
Reply-To: 	[email-masked]
Organization: 	The University of Aberdeen is a charity registered in 
Scotland, No SC013683.
To: 	[email-masked]
CC: 	Gorry Fairhurst <[email-masked]>, "Arjuna Sathiaseelan 
(work)" <[email-masked]>

ICCRG,

We have revised our draft called "Updating TCP to support Variable-Rate
Traffic". We think the feedback we received after ICCRG has been
addressed and are grateful to all who commented. This new version is
also intended to be easier to read.

Here is a summary of issues and NiTs that were corrected:
(1)	Non-validation phase time changed to 5 from 6 minutes,
	following comments that TCP aleady has a 5 minute timer.
(2)	Section 4.3.2:  At the end of the recovery phase, the TCP sender
	MUST reset the cwnd to (FlightSize-R)/2 and not FlightSize/2.
(3) 	Various places to improve language and address questions about
	ambiguities after iccrg.
(4)     Note change of author (Israfil has now moved-on to a job
	elsewhere).

We'd love more comments, and also like to know what happens next to this
draft. Are there more things that ICCRG wishes to think upon, or may we
now return to TCPM with a proposal to take this forward there?

Best wishes,

Gorry

From: [email-masked] (Michael Welzl)
Date: Fri Jun 22 08:27:54 2012
Subject: [Iccrg] Re: draft-fairhurst-tcpm-newcwv-03 - Status?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

First of all, the draft is here:
http://tools.ietf.org/html/draft-fairhurst-tcpm-newcwv-03

I think there were no public comments on the mailing list, just at the 
meeting @ IETF 80. Here they are:
http://www.ietf.org/proceedings/80/minutes/iccrg.txt

As for the question "may we now return to TCPM": we don't take a formal 
role in this process - i.e., you may decide to take this to TCPM at any 
time.

The point of ICCRG review is to get comments and incorporate feedback, 
up to a point where, if someone in TCPM says "this and that looks like 
open research, you should take this to ICCRG" you could ideally point to 
reviews that were already done there, and comments that were 
incorporated, thereby hopefully settling the discussion. If pointing to 
reviews can't settle it, this is going to make the document bounce back 
to ICCRG with a specific request from TCPM, which is also fine, but I 
think it would be most efficient to minimize (or, even better, 
altogether avoid) such iterations.

Since Gorry is saying that they'd love more comments, can I ask for 
volunteers to do a thorough review? For previous proposals of changes to 
TCP's congestion control, we had 2-3 such reviews.

Cheers,
Michael

On 6/21/12 4:43 PM, Gorry Fairhurst wrote:
> ICCRG,
>
> We have revised our draft called "Updating TCP to support
> Variable-Rate Traffic". We think the feedback we received after ICCRG
> has been addressed and are grateful to all who commented. This new
> version is also intended to be easier to read.
>
> Here is a summary of issues and NiTs that were corrected:
> (1)    Non-validation phase time changed to 5 from 6 minutes,
>     following comments that TCP aleady has a 5 minute timer.
> (2)    Section 4.3.2:  At the end of the recovery phase, the TCP sender
>     MUST reset the cwnd to (FlightSize-R)/2 and not FlightSize/2.
> (3)     Various places to improve language and address questions about
>     ambiguities after iccrg.
> (4)     Note change of author (Israfil has now moved-on to a job
>     elsewhere).
>
> We'd love more comments, and also like to know what happens next to
> this draft. Are there more things that ICCRG wishes to think upon, or
> may we now return to TCPM with a proposal to take this forward there?
>
> Best wishes,
>
> Gorry
>
>
>
>
>
>
>

From: [email-masked] (Yuchung Cheng)
Date: Wed Jun 20 17:49:48 2012
Subject: [Iccrg] Meeting in Vancouver
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <CAK6E8=cPfvnos2oZm1RqwOHe8VcMXZ4RjuKGsHKq+dhSLNwX=[email-masked]>

Hi Michael,

I'd like to sign up a 20 min talk titled "The GreatSnipe TCP
congestion manager".

Yu-chung

On Thu, May 31, 2012 at 4:51 AM, Michael Welzl <[email-masked]> wrote:
> Hi,
>
> We have requested a slot at the Vancouver IETF. If you want to give a talk,
> please send us the title and how much time you'd like to have.
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Mirja Kuehlewind)
Date: Sun Jun 10 22:44:03 2012
Subject: [Iccrg] Re: [conex] ECN marking over wireless networks
In-Reply-To: <[email-masked]>
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1> <[email-masked]>
Message-ID: <[email-masked]>

Hi Micheal,
 
just two quick comment on your two points:
>
> 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.
Yes, you should make the decision locally! But you need some information about 
the network state. ECN is only the signal protocol that provides you this 
information. ECN says you should react on this signal the same way as you 
would react to loss but that doesn't you have to halve your rate. ECN does 
not specify any action that will actually change your traffic; it's a signal 
protocol only.

>
> 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.
I believe that's the point we are talking about. In general ECN/RED should 
work no matter what network you are looking at. The only question is, if we 
know something specific about the link, as we do know for a mobile networks, 
can we do something better (like adjusting the RED parameters). And for 
mobile network, I believe, this will be specific for each operator as they 
know their network best.

Mirja

>
> 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, [email-masked] 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*
> > [email-masked] <mailto:[email-masked]>
> >
> >
> >
> > _______________________________________________
> > conex mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/conex
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja K?hlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

From: [email-masked] (Ingemar Johansson S)
Date: Fri Jun  8 13:08:01 2012
Subject: [Iccrg] RE: [conex] ECN marking over wireless networks
In-Reply-To: <[email-masked]>
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1> <[email-masked]>
Message-ID: <[email-masked]>

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:[email-masked]]
> Sent: den 7 juni 2012 11:14
> To: [email-masked]; [email-masked]
> 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, [email-masked] 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* [email-masked]
> > <mailto:[email-masked]>
> >
> >
> >
> > _______________________________________________
> > conex mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/conex
>
>
>

From: [email-masked] (Jim Gettys)
Date: Thu Jun  7 13:31:29 2012
Subject: [Iccrg] Re: [conex] ECN marking over wireless networks
In-Reply-To: <[email-masked]>
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1> <[email-masked]>
Message-ID: <[email-masked]>

On 06/07/2012 05:14 AM, Michael Welzl wrote:
> 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? 

Probably so: if you can only get 1Mbps, the idea of a single station
being able to starve a network that is primarily running 100x faster
seems broken.
 
> 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... 

"Fairness" in this case has to do with access to "air-time", I expect,
and not bandwidth.  I'm not convinced (in fact, I am pretty convinced of
the converse) that this is anything TCP can/should enforce at all, but
is something enforced by the wireless drivers in the AP. If there are
three stations actively "talking", I expect each one to get 1/3 of the
transmission opportunities.

Internal to the Linux wireless drivers, there are separate queues kept
for each station.  Note that we need to control the "aggregate"
delays/buffering, so to avoid very high latencies on a busy network, you
need to be able to mark across all the queues, not treat them as fully
independent queues; but as the "cost" of the packet is different
depending on the rate, the probabilities probably need adjustment. 
Exactly what the "best" strategy here is TBD.  Come help figure out what
TBD is....

With 802.11n aggregation, this all gets "interesting", as in the Chinese
curse....

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

There are four queues in 802.11 that indeed have some real effect at a
fundamental level; but currently traffic is not necessarily dropped into
the correct queues.

This begs the question of proper classification/diffserv marking and
that mapping to those queues.

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

Most Linux drivers now use the MAC 802.11 framework; Minstrel is used in
MAC 802.11

http://linuxwireless.org/en/developers/Documentation/mac80211

What is used on other OS's I do not know.  But as Linux is heavily used
in home routers, I think the information below should be helpful.

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

Our experience with CeroWrt http://www.bufferbloat.net/projects/cerowrt
and http://cero2.bufferbloat.net/cerowrt/
<http://cero2.bufferbloat.net/cerowrt/>is informative on the topic:

0) there are many bugs that need to be fixed in different drivers. 
Infinite retransmit bugs have been found in several drivers.  The driver
we currently "trust" the most (or maybe "distrust" the least is a better
term) is the Atheros ath9k driver.

1) the current Linux 802.11 stack has serious over buffering and design
problems: in order to do good 802.11n aggregation, a large number of
packets currently get sucked out of the queue disciplines in Linux into
the driver (to be able to fill aggregation buffers).  Since ECN marking
goes on (in the current design) in the queue disciplines, this means
that marking only starts to happen much later than it should.  What is
more, some drivers have grossly too much buffering in the driver even
for 802.11n aggregation.  Again, the ath9k driver is currently
distrusted the least (Felix Fietkau having worked with Dave Taht to get
it reduced from > 130 packets to no more than 34 packets, which is still
way too much). Ideally, marking/dropping should be unified across the
queue disciplines and device drivers; but that's not how the queuing
works today.

Working through the redesign/refactoring of the 802.11 stack in light of
bufferbloat and the desire for good AQM (with or without use of ECN) has
begun, but it's not a trivial undertaking.

2) RED is (nearly) useless in wireless, as bandwidth is variable. Dave
Taht spend months (while we were hoping for and then waiting for CoDel)
experimenting with RED, and (as we were warned by Van) it's  impossible
to tune well in the face of such variable bandwidth.

Dave Taht is getting much, much better results (given that there is
still too much buffering in the drivers) using CoDel (specifically the
fq_codel discipline, which also does fair queueing).  The codel and
fq_codel AQM mechanisms were recently merged for release in Linux 3.5. 
Even with the extremely excessive buffering, we're seeing good
improvement using CoDel (without any of the tuning headaches).  Dave can
speak to this if he likes, when he comes up for air....

I have a number of conclusions:
    o anything observed on older versions of Linux is almost certainly
close to useless now.  There are just too many bugs, and too much
buffering in the current wireless stack to believe much can be learned
in terms of TCP performance, and certainly not working well enough to
inform anyone how TCP might be changed.  The right approach is to dig
into the implementations and iteratively test (and fix!) problems that
are uncovered.  If you just observe the system as a "black box" from the
outside, you won't get very far.
   o RED is the wrong AQM mechanism, particularly for wireless.  Note
that the codel/fq_codel line disciplines do implement ECN, so have fun
taking data!
   o view this as experimental computer science crossed with
engineering.  The problems are interesting, the code is available, and
you should all beat the heck out of the software.
   o we need a much larger set of people trying experiments and seeing
what works best. Come help!  CeroWrt has extensive network testing tools
already its image to help make this much easier.
                                Best regards,
                                        Jim

<http://cero2.bufferbloat.net/cerowrt/>
>
> 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, [email-masked] 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*
>> [email-masked] <mailto:[email-masked]>
>>
>>
>>
>> _______________________________________________
>> conex mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/conex
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Thu Jun  7 10:13:03 2012
Subject: [Iccrg] Re: [conex] ECN marking over wireless networks
In-Reply-To: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1>
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1>
Message-ID: <[email-masked]>

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, [email-masked] 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*
> [email-masked] <mailto:[email-masked]>
>
>
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

From: [email-masked] (Thomas Dreibholz)
Date: Fri Jun  1 21:50:39 2012
Subject: [Iccrg] Call for Papers of the PAMS 2013
Message-ID: <3837856.e1sPGZrGmO@lupo>

We apologize if you receive multiple copies of this CFP.

CALL FOR PAPERS

The 3rd International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS 2013)
In conjunction with the 27th IEEE International Conference on Advanced 
Information Networkingand Applications (AINA 2013)
Barcelona, Spain, March 25-28, 2013
http://simula.no/pams2013

The intent of our workshop is to bring together people from research and
industry, in order to provide a discussion forum for state-of-the-art topics
related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session
(with short presentations) to introduce preliminary ideas as well as work in
progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimization for Multi-Homed Systems
    * Multi-Homing in the Context of Future Internet

GENERAL CHAIRS:

    * Thomas Dreibholz, Simula Research Laboratory, Norway
    * Hakim Adhari, University of Duisburg-Essen, Germany

PROGRAM CHAIRS:

    * Martin Becke, University of Duisburg-Essen, Germany
    * Thomas Dreibholz, Simula Research Laboratory, Norway

PUBLICITY CHAIRS:

    * Glenford Mapp, Middlesex University, United Kingdom
    * Xing Zhou, Hainan University, China

PROGRAM COMMITTEE

    * Hakim Adhari, University of Duisburg-Essen, Germany
    * Nicola Altan, ista International, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Holger Bleul, DB Systel, Germany
    * Anna Brunstr?m, Karlstad University, Sweden
    * Ahmed Elmokashfi, Simula Research Laboratory, Norway
    * Kristian Evensen, Simula Research Laboratory, Norway
    * Ernst Gunnar Gran, Simula Research Laboratory, Norway
    * Seok Joo Koh, Kyungpook National University, South Korea
    * Amund Kvalbein, Simula Research Laboratory, Norway
    * Glenford Mapp, Middlesex University, United Kingdom
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, University of British Columbia, Canada
    * Esbold Unurkhaan, Mongolian University of Science and Technology, 
Mongolia
    * Andreas Timm-Giel, TU Hamburg-Harburg, Germany
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway
    * Xing Zhou, Hainan University, China

IMPORTANT DATES

    * Paper Submission Deadline:       October 01, 2012
    * Author Notification:             December 01, 2012
    * Camera-Ready Paper Submission:   January 06, 2013

CONTACT

For further information, please contact:

    * Thomas Dreibholz ([email-masked])
    * Hakim Adhari ([email-masked])

WEBSITE

http://simula.no/pams2013

From: [email-masked] (Matt Mathis)
Date: Fri Jun  1 19:44:24 2012
Subject: [Iccrg] Meeting in Vancouver
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <CAH56bmBKu2xdJ-6v=[email-masked]>

I would like to give an update on Laminar.  I can fit in 15 min.

Thanks,
--MM--
The best way to predict the future is to create it. ?- Alan Kay

On Thu, May 31, 2012 at 4:51 AM, Michael Welzl <[email-masked]> wrote:
> Hi,
>
> We have requested a slot at the Vancouver IETF. If you want to give a talk,
> please send us the title and how much time you'd like to have.
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg