Subject: [iccrg] Fwd: Experimental evaluation of minstrel with uplink traffic

From: Naeem Khademi <[email-masked]>
Date: Tue, 5 Nov 2013 17:55:47 -0800

A side note about minstrel and uplink TCP traffic based on the discussion
at ICCRG -- IETF88.

Naeem

---------- Forwarded message ----------
From: Michael Welzl <[email-masked]>
Date: Tue, Nov 5, 2013 at 5:53 PM
Subject: Re: Experimental evaluation of minstrel with uplink traffic
To: Naeem Khademi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

please cc  iccrg

Sent from my iPhone

On 5. nov. 2013, at 17:42, Naeem Khademi <[email-masked]> wrote:

FYI

---------- Forwarded message ----------
From: Naeem Khademi <[email-masked]>
Date: Tue, Nov 5, 2013 at 5:42 PM
Subject: Experimental evaluation of minstrel with uplink traffic
To: [email-masked]

Hi Andrew

This is a paper I presented at WoWMoM12: Experimental Evaluation of TCP
Performance in Multi-rate 802.11
WLANs"<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6263696>

Given the results in that, I'm not putting all the blames of few hundreds
of milliseconds on "minstrel" (sorry if you got the message that way :-))
as minstrel is probably the best RA scheme so far used in drivers (and also
the most common one I guess in Linux).

The delay (e.g. >400ms) caused in the scenarios I showed are mostly caused
by channel access contention (I initially responded to Jim G with that)
(very problematic in uplink scenarios, as AP gets the same share of channel
access as any other STA), and to a lesser extent by minstrel going down to
48 or 36 Mbps from 54Mbps (in .11g).

I hope that I wasn't creating confusion ;-).

Cheers,
Naeem

---

From: grenville armitage <[email-masked]>
Date: Wed, 06 Nov 2013 18:59:48 +1100

On 11/06/2013 12:55, Naeem Khademi wrote:
> A side note about minstrel and uplink TCP traffic based on the
> discussion at ICCRG -- IETF88.
	[..]
>> The delay (e.g. >400ms) caused in the scenarios I showed are mostly
>> caused by channel access contention (I initially responded to Jim G
>> with that) (very problematic in uplink scenarios, as AP gets the
>> same share of channel access as any other STA), and to a lesser
>> extent by minstrel going down to 48 or 36 Mbps from 54Mbps (in
>> .11g). I hope that I wasn't creating confusion ;-).

I think this is a very useful clarification of the delay you
saw in the WLAN part of your presentation, thanks!  Contention
induces a component of delay that is separate (and in addition
to) the usual buffering-induced delays.

cheers,
gja

---

From: Matt Mathis <[email-masked]>
Date: Wed, 6 Nov 2013 00:05:58 -0800

Is "contention" the load dependent part of the "channel arbitration" time?

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

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Tue, Nov 5, 2013 at 11:59 PM, grenville armitage
<[email-masked]>wrote:

> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

---

From: grenville armitage <[email-masked]>
Date: Thu, 07 Nov 2013 03:55:30 +1100

On 11/06/2013 18:59, grenville armitage wrote:
	[..]
>  Contention

Please ignore that line above -- inexplicable brain fade. What
I had _intended_ to write was a "+1" to Naeem's clarification
that contention for channel time is a more significant component
of delay than actual rate adaptation events in his experiments.
What my fingers typed, however....

cheers,
gja

---

From: Naeem Khademi <[email-masked]>
Date: Thu, 7 Nov 2013 23:55:42 -0800

I can't speak for Grenville, but I believe he did mean more than the
"back-off period (arbitration time, if that what it means)" when he wrote
on contention. Contention (and its consequences) in a broader
sense/definition, as the time it takes for a STA to successfully get the
channel from other STAs or AP and start transmitting its frame(s), includes
the the entire period of waiting time that contributes to the (here uplink)
latency.

One can possibly argue over the precise definition of the word "contention"
and equalize it to the "contention period" term in 802.11 standard but I
believe it is/was intended in broader sense.

Cheers,
Naeem

On Wed, Nov 6, 2013 at 12:05 AM, Matt Mathis <[email-masked]> wrote:

> On Tue, Nov 5, 2013 at 11:59 PM, grenville armitage <[email-masked]
> > wrote:
>
>>