The other area in which throughput suffers is when one tries to do bunch of small transactions on a congested link. Think of a web page that does a series of HTTP gets of small pieces of data (let's say each object is about 10 packets in size). Let's say the gets are from different HTTP servers. The client has do a bunch of DNS resolutions (3+ RTT each), open a bunch of TCP sessions (3+ RTT each), send a bunch of HTTP gets (1RTT each) and get the data (~2 RTT for the 10 packets), then close each session (4+ RTT). So that is about 15 RTTs per JPEG. For discussion, let's say the client fetches them sequentially rather than in parallel. I know, SPDY does this better - buts let's say this is a legacy client, or let's say that there are interdependencies and you have to fetch them sequentially.
Let's compare the time it takes to display the web pages on a link with 50 ms of delay (20 ms speed of light and 30 ms of buffering) to the time it takes to display the web pages on a link with 200 ms of delay (20 ms speed of light and 30 ms of buffering). So, we have 300 RTTs before we display the completed web page. 300 * 50ms == 1.5 seconds. 300 * 200ms = 6 seconds. If we were to use a "big buffer tail drop" example with 2 second RTTs, we would get 10 minutes to show the page. As we all know, there is a lot of work on the client/server to make web surfing better. IW10, SPDY, pacing and the like all aim to reduce the number of RTTs. The buffer management algorithms aim to reduce the RTTs. They work together to provide better throughput when mice travers a congested link. Bill VerSteeg -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Toke Høiland-Jørgensen Sent: Monday, April 27, 2015 9:01 AM To: Paolo Valente Cc: bloat Subject: Re: [Bloat] bufferbloat effects on throughput Paolo Valente <[email protected]> writes: > One question: how can one be sure (if it is possible) that the > fluctuation of the throughput of a TCP flow on a given node is caused > by bufferbloat issues in the node, and not by other factors (such as, > e.g., systematic drops in some other nodes along the path followed by > the flow, with the drops possibly even caused by different reasons > than bufferbloat)? You can't, and it might. However, if you measure a performance degradation that goes away when the link is idle, consider that a hint... :) -Toke _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
