jm + buffering   8

TCP incast
a catastrophic TCP throughput collapse that occurs as the number of storage servers sending data to a client increases past the ability of an Ethernet switch to buffer packets. In a clustered file system, for example, a client application requests a data block striped across several storage servers, issuing the next data block request only when all servers have responded with their portion (Figure 1). This synchronized request workload can result in packets overfilling the buffers on the client's port on the switch, resulting in many losses. Under severe packet loss, TCP can experience a timeout that lasts a minimum of 200ms, determined by the TCP minimum retransmission timeout (RTOmin).
incast  networking  performance  tcp  bandwidth  buffering  switch  ethernet  capacity 
november 2014 by jm
TCP incast vs Riak
An extremely congested local network segment causes the "TCP incast" throughput collapse problem -- packet loss occurs, and TCP throughput collapses as a side effect. So far, this is pretty unsurprising, and anyone designing a service needs to keep bandwidth requirements in mind.

However it gets worse with Riak. Due to a bug, this becomes a serious issue for all clients: the Erlang network distribution port buffers fill up in turn, and the Riak KV vnode process (in its entirety) will be descheduled and 'cannot answer any more queries until the A-to-B network link becomes uncongested.'

This is where EC2's fully-uncontended-1:1-network compute cluster instances come in handy, btw. ;)
incast  tcp  networking  bandwidth  riak  architecture  erlang  buffering  queueing 
february 2014 by jm
Traditional AQM is not enough!
Jim Gettys on modern web design, HTTP, buffering, and FIFO queues in the network.
Web surfing is putting impulses of packets, without congestion avoidance, into FIFO queues where they do severe collateral damage to anything sharing the link (including itself!). So today’s web behavior incurs huge collateral damage on itself, data centers, the edge of the network, and in particular any application that hopes to have real time behavior. How do we solve this problem?

tl;dr: fq_codel. Now I want it!
buffering  networking  internet  web  http  protocols  tcp  bufferbloat  jim-gettys  codel  fq_codel 
july 2013 by jm
An excellent writeup of the TCP bounded-buffer deadlock problem
on pages 146-149 of 'TCP/IP Sockets in C: Practical Guide for Programmers' by Michael J. Donahoo and Kenneth L. Calvert.
tcp  ip  bounded-buffer  deadlock  bugs  buffering  connections  distributed-systems 
july 2013 by jm
the TCP bounded buffer deadlock problem
I've wound up mentioning this twice in the past week, so it's worth digging up and bookmarking!
Under certain circumstances a TCP connection can end up in a "deadlock", where neither the client nor the server is able to write data out or read data in. This is caused by two factors. First, a client or server cannot perform two transactions at once; a read cannot be performed if a write transaction is in progress, and vice versa. Second, the buffers that exist at either end of the TCP connection are of limited size. The deadlock occurs when both the client and server are trying to send an amount of data that is larger than the combined input and output buffer size.
tcp  ip  bounded-buffer  deadlock  bugs  buffering  connections  distributed-systems 
july 2013 by jm
'The Impact of Copyright Policy Changes on Venture Capital Investment in Cloud Computing Companies' [pdf]
'Our results suggest that the Cablevision decision, [which was widely seen as easing certain ambiguities surrounding intellectual property], led to additional incremental investment in U.S. cloud computing firms that ranged from $728 million to approximately $1.3 billion over the two-and-a-half years after the decision. When paired with the findings of the enhanced effects of VC investment relative to corporate investment, this may be the equivalent of $2 to $5 billion in traditional R&D investment.'

via Fred Logue.
via:fplogue  law  ip  copyright  policy  cablevision  funding  vc  cloud-computing  investment  legal  buffering 
march 2013 by jm
BufferBloat: What's Wrong with the Internet? - ACM Queue
'A discussion with Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys' -- the big guns! Great discussion (via Tony Finch)
via:fanf  bufferbloat  networking  buffers  buffering  performance  load  tcp  ip 
december 2011 by jm
Jim Gettys and a star-studded cast explain the 'bufferbloat' problem breaking TCP/IP on modern consumer broadband
'the [large] buffers are confusing TCP’s RTT estimator; the delay caused by the buffers is many times the actual RTT on the path.' [..] 'by inserting big buffers into the network, we have violated the design presumption of all Internet congestion avoiding protocols: that the network will drop packets in a timely fashion.'  QoS traffic shaping avoids this -- hooray for Tomato firmware
jim-gettys  via:glen-gray  buffering  tcp  ip  internet  broadband  routers  from delicious
december 2010 by jm

Copy this bookmark: