* [Bloat] Bufferbloat research: Help required
[not found] <CAPoy_SWZESfxdWv-bp1cT+PrR6su3=S7w1cQOTwgmbA2JvG_tw@mail.gmail.com>
@ 2012-11-25 15:21 ` Dauran raza
2012-11-28 16:39 ` Dave Hart
0 siblings, 1 reply; 6+ messages in thread
From: Dauran raza @ 2012-11-25 15:21 UTC (permalink / raw)
To: bloat
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
Hi
My name is Dauran Raza and i am currently doing Masters in Computer Science
from University Paderborn. Currently i am researching on the Problem of
Bufferbloat for a course under Prof Holger Karl. I have been regularly
reading you articles on your websites about this problem and it has been
really helpfull. I have a problem which is not answered so far through any
research paper. I wanted to know is there any difference in Wired and
Wireless networks caused by this problem and can you guide me with any good
paper or article to read on.
Regards
Dauran Raza
[-- Attachment #2: Type: text/html, Size: 728 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bloat] Bufferbloat research: Help required
2012-11-25 15:21 ` [Bloat] Bufferbloat research: Help required Dauran raza
@ 2012-11-28 16:39 ` Dave Hart
2012-11-30 18:56 ` Mark Watson
0 siblings, 1 reply; 6+ messages in thread
From: Dave Hart @ 2012-11-28 16:39 UTC (permalink / raw)
To: Dauran raza; +Cc: bloat
On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza <dauran.raza@gmail.com> wrote:
> My name is Dauran Raza and i am currently doing Masters in Computer Science
> from University Paderborn. Currently i am researching on the Problem of
> Bufferbloat for a course under Prof Holger Karl. I have been regularly
> reading you articles on your websites about this problem and it has been
> really helpfull. I have a problem which is not answered so far through any
> research paper. I wanted to know is there any difference in Wired and
> Wireless networks caused by this problem and can you guide me with any good
> paper or article to read on.
I wish you well in your graduate studies, and I commend Prof. Holger
Karl for his interest in the topic. I am, however, cautious that I
don't want to do your research for you.
Briefly, as you would hopefully anticipate, wireless presents more
challenges to addressing bufferbloat than wired. For example, the
jitter (delay variability) is much worse than wired, and 802.11n
requires aggregation of multiple packets into one transmission to
achieve its higher throughputs vs. 802.11g, which further increases
jitter and complicates AQM.
Even ignoring wireless, gigabit wired is more challenging than 100
Mbit, again because techniques used to maximize peak throughput (such
as deeper transmit buffers and receive interrupt coalescing) tend to
make bufferbloat more of a challenge.
There's a theme here -- those developing network advancements have
tended to focus on maximizing achievable throughput without enough
consideration of the negative effects on bufferbloat, often (at least
historically) with no understanding of bufferbloat at all.
I pray I have not said too much already, and if I have, please convey
my apologies to Prof. Karl.
I suggest digging into the mailing list archives:
https://lists.bufferbloat.net/listinfo
I'd start with the bloat and bloat-devel lists, then the Codel-related
lists, and possibly other -devel and -commit lists. Also, if you make
yourself useful in one or more bufferbloat.net projects, you will gain
firsthand knowledge of the issues as well as personal relationships
with people well-versed in the issues.
Thanks for your interest,
Dave Hart
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bloat] Bufferbloat research: Help required
2012-11-28 16:39 ` Dave Hart
@ 2012-11-30 18:56 ` Mark Watson
2012-11-30 21:17 ` Simon Barber
2012-12-01 20:53 ` Michael Richardson
0 siblings, 2 replies; 6+ messages in thread
From: Mark Watson @ 2012-11-30 18:56 UTC (permalink / raw)
To: <davehart_gmail_exchange_tee@davehart.net>
Cc: <bloat@lists.bufferbloat.net>, Dauran raza
It's also interesting to note that cellular wireless systems have been designed with a primary objective of reducing packet loss, at the expense of delay and especially delay variability introduced by link layer ARQ and other schemes. This approach maximizes the throughput of a single long-lived TCP connection, which is not an especially common traffic pattern.
Furthermore, the throughput of a cellular wireless radio channel varies by orders of magnitude on fairly rapidly (channel conditions are reassessed hundreds of times per second): what was a reasonable sized buffer for the throughput at one moment becomes a bloated one a fraction of a second later.
Best,
Mark Watson
On Nov 28, 2012, at 8:39 AM, Dave Hart wrote:
> On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza <dauran.raza@gmail.com> wrote:
>> My name is Dauran Raza and i am currently doing Masters in Computer Science
>> from University Paderborn. Currently i am researching on the Problem of
>> Bufferbloat for a course under Prof Holger Karl. I have been regularly
>> reading you articles on your websites about this problem and it has been
>> really helpfull. I have a problem which is not answered so far through any
>> research paper. I wanted to know is there any difference in Wired and
>> Wireless networks caused by this problem and can you guide me with any good
>> paper or article to read on.
>
> I wish you well in your graduate studies, and I commend Prof. Holger
> Karl for his interest in the topic. I am, however, cautious that I
> don't want to do your research for you.
>
> Briefly, as you would hopefully anticipate, wireless presents more
> challenges to addressing bufferbloat than wired. For example, the
> jitter (delay variability) is much worse than wired, and 802.11n
> requires aggregation of multiple packets into one transmission to
> achieve its higher throughputs vs. 802.11g, which further increases
> jitter and complicates AQM.
>
> Even ignoring wireless, gigabit wired is more challenging than 100
> Mbit, again because techniques used to maximize peak throughput (such
> as deeper transmit buffers and receive interrupt coalescing) tend to
> make bufferbloat more of a challenge.
>
> There's a theme here -- those developing network advancements have
> tended to focus on maximizing achievable throughput without enough
> consideration of the negative effects on bufferbloat, often (at least
> historically) with no understanding of bufferbloat at all.
>
> I pray I have not said too much already, and if I have, please convey
> my apologies to Prof. Karl.
>
> I suggest digging into the mailing list archives:
>
> https://lists.bufferbloat.net/listinfo
>
> I'd start with the bloat and bloat-devel lists, then the Codel-related
> lists, and possibly other -devel and -commit lists. Also, if you make
> yourself useful in one or more bufferbloat.net projects, you will gain
> firsthand knowledge of the issues as well as personal relationships
> with people well-versed in the issues.
>
> Thanks for your interest,
> Dave Hart
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bloat] Bufferbloat research: Help required
2012-11-30 18:56 ` Mark Watson
@ 2012-11-30 21:17 ` Simon Barber
2012-12-01 20:53 ` Michael Richardson
1 sibling, 0 replies; 6+ messages in thread
From: Simon Barber @ 2012-11-30 21:17 UTC (permalink / raw)
To: Mark Watson
Cc: Dauran raza, <davehart_gmail_exchange_tee@davehart.net>,
<bloat@lists.bufferbloat.net>
Both cellular and wireless lan suffer from the same problem - in some
situations a packet loss rate of 30% can be optimal operation for best
throughput before stepping down a rate at the physical layer. Obviously
TCP was not designed to handle this level of loss, so a 'wire like'
emulation layer is used, with retries. Unfortunately the number of
retries is fixed, and non optimal, causing problems.
Simon
On Fri 30 Nov 2012 10:56:59 AM PST, Mark Watson wrote:
> It's also interesting to note that cellular wireless systems have been designed with a primary objective of reducing packet loss, at the expense of delay and especially delay variability introduced by link layer ARQ and other schemes. This approach maximizes the throughput of a single long-lived TCP connection, which is not an especially common traffic pattern.
>
> Furthermore, the throughput of a cellular wireless radio channel varies by orders of magnitude on fairly rapidly (channel conditions are reassessed hundreds of times per second): what was a reasonable sized buffer for the throughput at one moment becomes a bloated one a fraction of a second later.
>
> Best,
>
> Mark Watson
>
>
> On Nov 28, 2012, at 8:39 AM, Dave Hart wrote:
>
>> On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza <dauran.raza@gmail.com> wrote:
>>> My name is Dauran Raza and i am currently doing Masters in Computer Science
>>> from University Paderborn. Currently i am researching on the Problem of
>>> Bufferbloat for a course under Prof Holger Karl. I have been regularly
>>> reading you articles on your websites about this problem and it has been
>>> really helpfull. I have a problem which is not answered so far through any
>>> research paper. I wanted to know is there any difference in Wired and
>>> Wireless networks caused by this problem and can you guide me with any good
>>> paper or article to read on.
>>
>> I wish you well in your graduate studies, and I commend Prof. Holger
>> Karl for his interest in the topic. I am, however, cautious that I
>> don't want to do your research for you.
>>
>> Briefly, as you would hopefully anticipate, wireless presents more
>> challenges to addressing bufferbloat than wired. For example, the
>> jitter (delay variability) is much worse than wired, and 802.11n
>> requires aggregation of multiple packets into one transmission to
>> achieve its higher throughputs vs. 802.11g, which further increases
>> jitter and complicates AQM.
>>
>> Even ignoring wireless, gigabit wired is more challenging than 100
>> Mbit, again because techniques used to maximize peak throughput (such
>> as deeper transmit buffers and receive interrupt coalescing) tend to
>> make bufferbloat more of a challenge.
>>
>> There's a theme here -- those developing network advancements have
>> tended to focus on maximizing achievable throughput without enough
>> consideration of the negative effects on bufferbloat, often (at least
>> historically) with no understanding of bufferbloat at all.
>>
>> I pray I have not said too much already, and if I have, please convey
>> my apologies to Prof. Karl.
>>
>> I suggest digging into the mailing list archives:
>>
>> https://lists.bufferbloat.net/listinfo
>>
>> I'd start with the bloat and bloat-devel lists, then the Codel-related
>> lists, and possibly other -devel and -commit lists. Also, if you make
>> yourself useful in one or more bufferbloat.net projects, you will gain
>> firsthand knowledge of the issues as well as personal relationships
>> with people well-versed in the issues.
>>
>> Thanks for your interest,
>> Dave Hart
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bloat] Bufferbloat research: Help required
2012-11-30 18:56 ` Mark Watson
2012-11-30 21:17 ` Simon Barber
@ 2012-12-01 20:53 ` Michael Richardson
2012-12-01 21:47 ` Simon Barber
1 sibling, 1 reply; 6+ messages in thread
From: Michael Richardson @ 2012-12-01 20:53 UTC (permalink / raw)
To: Mark Watson
Cc: Dauran raza, <davehart_gmail_exchange_tee@davehart.net>,
<bloat@lists.bufferbloat.net>
>>>>> "Mark" == Mark Watson <watsonm@netflix.com> writes:
Mark> It's also interesting to note that cellular wireless [DATA] systems
Mark> have been designed with a primary objective of reducing packet
Mark> loss, at the expense of delay and especially delay variability
Mark> introduced by link layer ARQ and other schemes. This approach
Mark> maximizes the throughput of a single long-lived TCP
Mark> connection, which is not an especially common traffic
Mark> pattern.
A question, given that I inserted [DATA].
I wonder to what extent the pre-LTE systems were designed this way in
part to make sure that voice over data would always be crappy?
The LTE roadmap says that voice is now over data, so it's now in the
carrier's interest to do things differently.
Mark> Furthermore, the throughput of a cellular wireless radio
Mark> channel varies by orders of magnitude on fairly rapidly
Mark> (channel conditions are reassessed hundreds of times per
Mark> second): what was a reasonable sized buffer for the throughput
Mark> at one moment becomes a bloated one a fraction of a second
Mark> later.
Does ECN help us here?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bloat] Bufferbloat research: Help required
2012-12-01 20:53 ` Michael Richardson
@ 2012-12-01 21:47 ` Simon Barber
0 siblings, 0 replies; 6+ messages in thread
From: Simon Barber @ 2012-12-01 21:47 UTC (permalink / raw)
To: Michael Richardson
Cc: <bloat@lists.bufferbloat.net>,
<davehart_gmail_exchange_tee@davehart.net>,
Dauran raza
Voice over data can actually work very well in 3G networks (better than
dedicated voice even), but it requires prioritisation. There is a bunch
of work going on to enable this in existing networks to support the new
services that VoLTE will enable, over older networks (Joyn). This is a
*huge* transition in carrier networks, and will take some time to
arrive. Even today only 1 US carrier uses VoLTE, all the others switch
to 3G to make or receive a phone call.
Simon
On Sat 01 Dec 2012 12:53:13 PM PST, Michael Richardson wrote:
>
>>>>>> "Mark" == Mark Watson <watsonm@netflix.com> writes:
> Mark> It's also interesting to note that cellular wireless [DATA] systems
> Mark> have been designed with a primary objective of reducing packet
> Mark> loss, at the expense of delay and especially delay variability
> Mark> introduced by link layer ARQ and other schemes. This approach
> Mark> maximizes the throughput of a single long-lived TCP
> Mark> connection, which is not an especially common traffic
> Mark> pattern.
>
> A question, given that I inserted [DATA].
>
> I wonder to what extent the pre-LTE systems were designed this way in
> part to make sure that voice over data would always be crappy?
>
> The LTE roadmap says that voice is now over data, so it's now in the
> carrier's interest to do things differently.
>
> Mark> Furthermore, the throughput of a cellular wireless radio
> Mark> channel varies by orders of magnitude on fairly rapidly
> Mark> (channel conditions are reassessed hundreds of times per
> Mark> second): what was a reasonable sized buffer for the throughput
> Mark> at one moment becomes a bloated one a fraction of a second
> Mark> later.
>
> Does ECN help us here?
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-12-01 21:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAPoy_SWZESfxdWv-bp1cT+PrR6su3=S7w1cQOTwgmbA2JvG_tw@mail.gmail.com>
2012-11-25 15:21 ` [Bloat] Bufferbloat research: Help required Dauran raza
2012-11-28 16:39 ` Dave Hart
2012-11-30 18:56 ` Mark Watson
2012-11-30 21:17 ` Simon Barber
2012-12-01 20:53 ` Michael Richardson
2012-12-01 21:47 ` Simon Barber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox