From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4F5443B2B9; Fri, 3 Jun 2016 21:01:03 -0400 (EDT) Received: by mail-yw0-x236.google.com with SMTP id o16so95772888ywd.2; Fri, 03 Jun 2016 18:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zMDxtSERF8OLgmj4lcabWqSyoxt16cniBrAgV7xqWeo=; b=qM2HgRQAo1E97gxZ1OkKOVCOwHoals318cfgyzqxkelzO/VR9jWw5JYlHux8pvb/oj vb+nAqHcJCyZPtADCoY50xDDzzI+Egw6t0OLK7WXBOtIGlZWlSDagE6mHRYq3CpvO7A3 k/2anwRfxP83UShpVXXmbONYQwpGZCr9n8Ez7EJ3SYk+MMCzc5vz/grtXT1kM9D2F/N2 KN4BBVVVj6bY0kxBBbeU1aLsie6d9beIklUBvkUKvR2TvABGu/DKcVeVBoIN+jLVxqsN v8VIUujHxVhJn7/YZO+i0SAIJCkD6OxNSE+LWyWPqMpzjcmgPykgyteupU1j9ao+TC1+ 6ecw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zMDxtSERF8OLgmj4lcabWqSyoxt16cniBrAgV7xqWeo=; b=eN8vgeYH2shebvZyADgNAdCbcWMfK3Yy9yFftG6LGS6PJm9SNY1+VWuVibtY8xR5Hk 5wTSJJUdMlH5eIJbf6zkegaE8Uk9hfsKF3G2d65viOvkpoVBej3W/jq8jKVrET7F/5mh mMZebZktSDep/OMwjkROA0e5R307M0TPv15/qiWuszxCFmTqFLCNdaCKtmt5JOZp2/xX hSiFX9eDL+qvFjew1x0Olhi6iZJeWWC2RB/jEqvthLkOdZHUMou0EjyKsaUmMv7qdo8e uCgjhKUZ5ybE1zMvKlQEoA8Edl6dlZnb193rcrhYUYd0pNKUJvP/1NFkzDpgU+1g72in CvSA== X-Gm-Message-State: ALyK8tIiEHACAoNOiOw51+gXluElySBwJ+hFrSvYLdkqkh5vhqfhGUn6oqDmNhEHAvg9CX+TAOmZJWR3z6jtDA== X-Received: by 10.129.45.196 with SMTP id t187mr4745096ywt.153.1465002062745; Fri, 03 Jun 2016 18:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.31.212 with HTTP; Fri, 3 Jun 2016 18:01:01 -0700 (PDT) In-Reply-To: <48A25043-19E2-4BB7-B634-A4003F7BE6F8@gmail.com> References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> <8AB0D25D-C1CA-45F1-889E-2F73CF8C44F7@gmail.com> <323AFC22-A092-4F59-8197-AF21EF73FD58@gmail.com> <274D3A0FA900FD47AA6B56991AAA32FDC5529FC8@wtl-exchp-1.sandvine.com> <574478B4.7080103@taht.net> <39F38477-A877-4C1B-9B7F-BB3358425F17@gmail.com> <0eb223f9-2873-7f53-c2ce-c6867ddec17c@gmail.com> <48A25043-19E2-4BB7-B634-A4003F7BE6F8@gmail.com> From: Andrew McGregor Date: Sat, 4 Jun 2016 11:01:01 +1000 Message-ID: To: Jonathan Morton Cc: Noah Causin , cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] [Cake] Proposing COBALT X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 01:01:03 -0000 There are undoubtedly DCTCP-like ECN responses widely deployed, since that is the default behaviour in Windows Server (gated on RTT in some versions). But also, ECN bleaching exists, as do servers with ECN response turned off even though they negotiate ECN. It would be good to know some specifics as to which site, whose DC they're hosted in, etc. Also, do you have fallback behaviour such that an ECN-unresponsive flow eventually sees drops? I think that will be essential. On Sat, Jun 4, 2016 at 5:34 AM, Jonathan Morton wro= te: > >> On 3 Jun, 2016, at 22:09, Noah Causin wrote: >> >> Was the issue, where the drops and marks did not seem to occur, resolved= ? > > Examination of packet dumps obtained under controlled conditions showed t= hat marking and dropping *did* occur as normal, and I got a normal response= from a local machine sending through a virtual delay line. My Internet co= nnection is such that extremely short RTTs never occur. > > However, it seems that some Internet servers I use often do not respond a= s much as they should to ECN marking, resulting in excessively long queues = despite a relatively small number of flows. > > It rather reminds me of the symptoms one would expect to see if DCTCP fou= nd its way onto the public Internet. And these are very popular servers wi= th an extremely large userbase. However it=E2=80=99s also possible that th= e ECN information is somehow disappearing en route. > > I plan to investigate in more detail once COBALT is up and running, with = behaviour I can reason about more intuitively than the =E2=80=9Cevolved Cod= el=E2=80=9D Cake has been using up to now. With COBALT integrated into Cak= e, I=E2=80=99ll also be able to directly track the number of unresponsive f= lows. > > Part of that investigation may be to enquire as to whether DCTCP is in fa= ct in use. If so, the TCP Prague people should be brought into the loop, a= s this would constitute evidence that Codel can=E2=80=99t control DCTCP via= ECN under practical Internet conditions. > > - Jonathan Morton > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel