30 Nov 2011 12:10
Reasons not to deply TCP BIC/Cubic
<mascolo <at> poliba.it>
2011-11-30 11:10:50 GMT
2011-11-30 11:10:50 GMT
Dear all, we know that TCP BIC/Cubic is default in Linux and as a consequence 50% of servers employs TCP BIC/Cubic. Our measurements say that there could be reasons not to deploy TCP BIC/Cubic. These reasons are in our opinion rooted in its more aggressive probing phase. In particular, in common network conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or Westwood+. In other terms, it seems that its more aggressive probing increases both throughput and retransmissions but leaving unchanged the goodput. This is neutral for the users but negative for the network. I appreciate your views. Thanks for the attention and best regards, Saverio Mascolo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
> I see TCP as a control system with a delayed feedback loop.
This is an always interesting analogy - however, at least to me, not a
very helpful one. (And I well expect criticism by Saverio here. IIRC,
Saverio did quite a lot of work on analytical models for TCP. However,
all these analytical discussions which are necessary for doing control
theoretical considerations, did not yet convince me.)
> The feedback is an ACK or a dupAck. How quickly a TCP reacts is completely dependent on RTT (how long it takes
for the feedback signal to return to the sender). If I send a packet and it is lost, I will not know it until the
ACK from the next packet reaches me. If the packet is received, I should know about it slightly sooner. This
is how quickly a TCP can react to changes in the network.
Exactly. And if you introduce queuing delay into the network, you will
slow down the reaction significantly.
So I can ask the author himself: Why?
>>> I see TCP as a control system with a delayed feedback loop.
>> This is an always interesting analogy - however, at least to me, not a very
>> helpful one.
> It isn't an analogy. Congestion control *is* a control system. It is
> just not a simple one, and all tractable analyses have to model it as
> something much simpler than it is.
>
O.k., "not a simple one" is the correct view. Obviously, a simple view
into the congavoid paper will help us here:
Look at the footnote on page 2:
> A conservative flow means that for any given time, the integral of the
> packet density around the sender–
> receiver–sender loop is a constant. Since packets have to ‘diffuse’
> around this loop, the integral is sufficiently
> continuous to be a Lyapunov function for the system. A constant
> function trivially meets the conditions for
> Lyapunov stability so the system is stable and any superposition of
> such systems is stable. (See [3], chap. 11–
> 12 or [21], chap. 9 for excellent introductions to system stability
> theory.)
RSS Feed