From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 CFAAD21F14D for ; Sun, 22 Nov 2015 06:38:04 -0800 (PST) Received: by lbbsy6 with SMTP id sy6so83590165lbb.2 for ; Sun, 22 Nov 2015 06:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s7l0NZwOk3d0hanKRcoPfEVyba00HeikhZjFGGgjMKU=; b=GbfnJxwz/11ef6U48DtAwgd+3OMMt6u8jYUiY0h9ubmpKwL3QEigYw6mjvj7Ds/yH/ 3s1FYmH1JP0fNPIipz1LDrQCkJGwdKlCyOn7LXlAQtxmC/BOlsR2V/X0avnGnz25jWE1 nQjVVtxpJU85P1f3FDuehK2gSLQ+le1XHHkvB6FOy4/SQmE+juFZrAAKD1XEty2oydBr WVJMufp0nsbib3aJPT9mgVBBWVE9st1bfN5R8mzaSrJ4xQqoHLKtTJ6AxNuG+ssZipy1 1gF3who3vZqHvegHHF9zTC7jWTw9WYtV+OR9dVEKSuKNGk9LWfQvDfjQBUoqYDbszZ8P lLlw== X-Received: by 10.112.141.201 with SMTP id rq9mr9142676lbb.4.1448203081817; Sun, 22 Nov 2015 06:38:01 -0800 (PST) Received: from bass.home.chromatix.fi (83-245-246-100-nat-p.elisa-mobile.fi. [83.245.246.100]) by smtp.gmail.com with ESMTPSA id g5sm1187032lbd.26.2015.11.22.06.38.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Nov 2015 06:38:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Jonathan Morton In-Reply-To: <5651C3CA.4000104@darbyshire-bryant.me.uk> Date: Sun, 22 Nov 2015 16:37:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <519F40AC-6AE2-4799-AF7F-25F1BE5E68FD@gmail.com> References: <5651C3CA.4000104@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3096.5) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] GSO super-packets, classification (tin) & DSCP washing X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 14:38:27 -0000 > On 22 Nov, 2015, at 15:31, Kevin Darbyshire-Bryant = wrote: >=20 > First off, DSCP washing as implemented, only washes the GSO = packet..I'm > assuming effectively the first contained packet only. This is = unfortunate. You seem to misunderstand how GSO works. A GSO aggregate is, by definition, a single packet formed from the = contents of several consecutive inbound packets with identical IP = headers and =E2=80=9Ccompatible" transport headers, stored and handled = with a *single* copy of the IP and transport header, in such a way that = a sequence of outbound packets with identical semantics (but not = necessarily identical sizes) can be reassembled from them. Because there is only one IP header, altering that header implicitly = alters the headers of the reassembled packets in the same way. This = applies both to DSCP washing and ECN marking. The more vexing potential problem is where Cake drops a GSO aggregate, = resulting in several MTUs at once being dropped. It was suggested that = this might lead to a more aggressive than necessary congestion response = from TCP. However, I=E2=80=99m not convinced that this is really a = problem in practice, since a sequence of consecutive drops doesn=E2=80=99t= produce any more DupACKs than a single drop, and SACK will immediately = and correctly identify which packets to retransmit. Certainly this = won=E2=80=99t be any worse than the typical burst-loss from overflowing = a dumb FIFO, so I=E2=80=99d like to see a demonstration before trying to = do anything about it. - Jonathan Morton