From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DB07221F38B for ; Fri, 3 Apr 2015 00:45:38 -0700 (PDT) Received: by ykcn8 with SMTP id n8so27744977ykc.3 for ; Fri, 03 Apr 2015 00:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0D4huvK9taC869kcRJrgGMnRGJSf23WqaoUsA7R4syQ=; b=YO3UQW4t7U5yAQpoRddKQJh2GEqSCO70UIHMVr4TfyNXcwRINrBlRp59TH0HWz3iXd djHSx9GKdxTA1IlhcicD+ahWlDUlW8nIn7cixUEndwaPzqM7OYVJsUHtbZP92RmdnbCM FLgmhKstOXQtHt34G3KExX2q42QgrlYhpga1493X8lco+9llxvZ1t5imqXPi/cwQvNuZ BVngHnG2mBYm5EJmb6yHOSEeAfMffNARyxAUQw/AiwmrjloeDhfwdG1Xbdl8IUS1pyJC BkcA+r8hYTn7LfYfp9EUeydjbtl79oucfTkl+ORbNtkv8DKCjg0/+QAconOANjW2UBXr pGhg== MIME-Version: 1.0 X-Received: by 10.52.81.1 with SMTP id v1mr727964vdx.96.1428047137184; Fri, 03 Apr 2015 00:45:37 -0700 (PDT) Received: by 10.52.240.145 with HTTP; Fri, 3 Apr 2015 00:45:37 -0700 (PDT) Received: by 10.52.240.145 with HTTP; Fri, 3 Apr 2015 00:45:37 -0700 (PDT) In-Reply-To: <551E364D.3070006@superduper.net> References: <551E364D.3070006@superduper.net> Date: Fri, 3 Apr 2015 10:45:37 +0300 Message-ID: From: Jonathan Morton To: Simon Barber Content-Type: multipart/alternative; boundary=001a1136744455a03b0512cd2265 Cc: bloat Subject: Re: [Bloat] Computer generated congestion control X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 07:46:07 -0000 --001a1136744455a03b0512cd2265 Content-Type: text/plain; charset=UTF-8 I think we've seen that before. The headline results are certainly impressive. But there's a big caveat, which is in fact revealed by the authors. Remy works by tailoring the congestion control algorithm to the network characteristics that it's been told about. If the actual network it's running on matches those characteristics, then the results are good. The more specific that information is, the better the results. But if the network characteristics differ from the information given, the results are bad - and the more specific the data was, the more likely a mismatch will occur. If we simply knew, a priori, what the delay bandwidth product was for a given connection, we wouldn't need congestion control algorithms in the first place, as we could simply maintain the congestion window at that value. That need for a priori knowledge is a fundamental problem with Remy's approach. So while existing, hand written congestion control algorithms aren't perfect, in practice they tend to do a competent job in difficult circumstances, using the limited information available to them. If anything, I'd like them to put some sane upper bound on the RTT - one compatible with satellite links, but which would avoid flooding unmanaged buffers to multi-minute delays. But when they get an unambiguous congestion signal, they respond, and so they adapt to the myriad varieties of link characteristics actually found on real networks. - Jonathan Morton --001a1136744455a03b0512cd2265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think we've seen that before. The headline results are= certainly impressive. But there's a big caveat, which is in fact revea= led by the authors.

Remy works by tailoring the congestion control algorithm to = the network characteristics that it's been told about. If the actual ne= twork it's running on matches those characteristics, then the results a= re good. The more specific that information is, the better the results. But= if the network characteristics differ from the information given, the resu= lts are bad - and the more specific the data was, the more likely a mismatc= h will occur.

If we simply knew, a priori, what the delay bandwidth produc= t was for a given connection, we wouldn't need congestion control algor= ithms in the first place, as we could simply maintain the congestion window= at that value. That need for a priori knowledge is a fundamental problem w= ith Remy's approach.

So while existing, hand written congestion control algorithm= s aren't perfect, in practice they tend to do a competent job in diffic= ult circumstances, using the limited information available to them. If anyt= hing, I'd like them to put some sane upper bound on the RTT - one compa= tible with satellite links, but which would avoid flooding unmanaged buffer= s to multi-minute delays. But when they get an unambiguous congestion signa= l, they respond, and so they adapt to the myriad varieties of link characte= ristics actually found on real networks.

- Jonathan Morton

--001a1136744455a03b0512cd2265--