From: sahil grover <sahilgrover013@gmail.com>
To: David Lang <david@lang.hm>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Requirements for bufferbloat to occur
Date: Thu, 9 Apr 2015 15:56:53 +0530 [thread overview]
Message-ID: <CADnS-2hyY8GMZEO1E2bNBFr3Xz0=NeJYj7tJTbLGwgVEOY2AhQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1503291037430.26044@nftneq.ynat.uz>
[-- Attachment #1: Type: text/plain, Size: 4438 bytes --]
Hi David Sir,
Sorry for replying late..but i was v. busy with some other work.
Thanks for the detailed explaination
and yes ofcourse, it helped.
Thanks a lot for clearing my doubts.
On Sun, Mar 29, 2015 at 11:32 PM, David Lang <david@lang.hm> wrote:
> On Sun, 29 Mar 2015, sahil grover wrote:
>
> can you please explain me the concept of delay-bandwidth product,window
>> size and buffer size(or something related with pipe size and packets in
>> flight).
>>
>
>
> These are several different concepts, all related to network perfromance,
> but most unrelated to buffer sizing.
>
> Any network connection is either 100% used, or idle if you look at a small
> enough timeframe. When the network connection finishes sending one packet,
> it is idle until the next packet is available to send. If there is no
> buffer, the connection is idle until the software generates new data to
> send. since this takes time, the connection will be idle. As a result, you
> want to have some buffer so that the software can generate the traffic a
> little earlier than it's needed so that as soon as the network finishes
> sending one packet, it has the next packet available to send.
>
> when you have a router that is receving packets from multiple computers
> and sending it out one link, buffers become even more important, if you
> have two computers send you a packet at the same time, without a buffer
> youc an only send one and the other will have to be dropped. so you need to
> have a buffer to hold the second packet so you can send it out as soon as
> you have time.
>
> bufferbloat is when the buffers are "too large" for the output connection
> and you end up with "too much" data sitting in the buffers waiting to be
> sent. The problem with trying to size buffers is that how long it takes to
> transmit the data in the buffer depends on how large the packets in teh
> buffer are and how fast the connection is. Traditionally, buffers were
> sized in terms of X packets. If you have a buffer that can hold 10ms worth
> of 75 byte packets at 1Gb/sec, but you are connected to a DSL line with an
> upload spped of 1Mb/sec and are sending 1500 byte packets, then your buffer
> now holds 200,000ms worth of traffic.
>
> TCP ramps up it's sending speed until it looses packets (or gets an ECN
> signal), no packets will be dropped until the buffer fills up (in addition
> to the traffic that gets sent), so the buffer will fill up and everything
> that you try to do, including DNS lookups, gaming, VoIP, etc is going to be
> delayed by how long it takes to get through the buffer.
>
>
> window size, delay-bandwidth product, etc are a different aspect of the
> network stack. they limit a little bit how much traffic a single TCP
> connection will try to send without receiving any ack packets for the data.
> The idea is that if you have a 1Gb/s connection, and a 1sping time, to keep
> the connection full you should have 1Gb of taffic "in flight" (i.e. that
> you have sent and not yet received acks for). If your window of allowd
> unacked data is less than this, then you send your limit, then the
> connection goes idle until the receiving side sends the asks
>
> Since the system doesn't actually know how long the path is, or the
> available bandwidth, it again is guessing this and ramping it up until it
> runs into trouble and then slows down
>
>
> so back to your questions, the delay of the link times the bandwidth of
> the link (delay-banseidth produt) determins the ideal window size for a
> given TCP connection. This determins the minimum size of a buffer of
> unacknowleged packets that a system has transmitted. This has _nothing_ to
> do with the buffer size for packets that a system or rotuer is waiting to
> transmit. Bufferbloat happens on the buffer for packets that are waiting to
> be transmitted. a few ms worth of buffering for packets waiting to be
> transmitted is necessary to keep the connection busy, bufferbloat happens
> when these queues get much larger than this minimum value. There isn't a
> hard limit that separates bloat from non-bloat, but if your queues are over
> a second, you are very clearly way beyond a reasonable size buffer. 10s of
> ms is probably reasonable, 100s of ms is probably not.
>
> Does this help?
>
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
[-- Attachment #2: Type: text/html, Size: 5328 bytes --]
prev parent reply other threads:[~2015-04-09 10:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-29 8:04 sahil grover
2015-03-29 9:09 ` Jonathan Morton
2015-03-29 16:34 ` sahil grover
2015-03-29 17:02 ` sahil grover
2015-03-29 18:02 ` David Lang
2015-04-09 10:26 ` sahil grover [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADnS-2hyY8GMZEO1E2bNBFr3Xz0=NeJYj7tJTbLGwgVEOY2AhQ@mail.gmail.com' \
--to=sahilgrover013@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=david@lang.hm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox