Re: [tcpm] Better QoS for TCP ACK question
Toerless Eckert <tte@cs.fau.de> Mon, 16 April 2018 16:45 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2084E124207 for <tcpm@ietfa.amsl.com>; Mon, 16 Apr 2018 09:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry8_qsb13-Ql for <tcpm@ietfa.amsl.com>; Mon, 16 Apr 2018 09:45:17 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F2B12DA13 for <tcpm@ietf.org>; Mon, 16 Apr 2018 09:45:17 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8273658C4B1; Mon, 16 Apr 2018 18:45:13 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7584F440214; Mon, 16 Apr 2018 18:45:13 +0200 (CEST)
Date: Mon, 16 Apr 2018 18:45:13 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, tcpm@ietf.org
Message-ID: <20180416164513.wu4wwzuw5fgslrgt@faui48f.informatik.uni-erlangen.de>
References: <20180406012736.fpayup7perbhqn2p@faui48f.informatik.uni-erlangen.de> <alpine.DEB.2.20.1804070706040.18650@uplift.swm.pp.se> <df12f8ae-ef1a-98be-1a6d-d147143c7736@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <df12f8ae-ef1a-98be-1a6d-d147143c7736@erg.abdn.ac.uk>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/kU29COaAgTeT6sNJrUGM-MUVGMw>
Subject: Re: [tcpm] Better QoS for TCP ACK question
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2018 16:45:20 -0000
On Mon, Apr 16, 2018 at 04:42:12PM +0100, Gorry Fairhurst wrote: > Just to send something more to this list thread: > > RFC 3449 from 2002 describes this in section 5.4.2 on ACKs-first Scheduling. Ah, great. Thanks. Something to point people to. > I aware this method was implemented in a variety of equipment around that > time, although I suspect it can also cause some odd performance hits when > using app-limited TCP sessions (where many data segments are also small and > may also become reordered). > Gorry I guess this would refer not to an actual TCP-ACK DPI based scheduling that you could easily do on CPU processing home gateways, but rather the packet-length based queuing Mikael brought up ? Otherwise i don't understand. Toerless
- [tcpm] Better QoS for TCP ACK question Toerless Eckert
- Re: [tcpm] Better QoS for TCP ACK question Mikael Abrahamsson
- Re: [tcpm] Better QoS for TCP ACK question Gorry Fairhurst
- Re: [tcpm] Better QoS for TCP ACK question Toerless Eckert
- Re: [tcpm] Better QoS for TCP ACK question Gorry Fairhurst