IETF Logo Mail Archive

Re: [EToSat] QUIC ACK Strategy

Ted Hardie <ted.ietf@gmail.com> Tue, 16 April 2019 21:41 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBA312020A for <etosat@ietfa.amsl.com>; Tue, 16 Apr 2019 14:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1ZztoeyWgW0M for <etosat@ietfa.amsl.com>; Tue, 16 Apr 2019 14:41:41 -0700 (PDT)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345E41201E8 for <etosat@ietf.org>; Tue, 16 Apr 2019 14:41:41 -0700 (PDT)
Received: by mail-it1-x12d.google.com with SMTP id a190so1216308ite.4 for <etosat@ietf.org>; Tue, 16 Apr 2019 14:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5P2Rj5Xwy+anik/zY/xl7XSVN23ef3NJZYuLPnVj1mI=; b=ueqfVqAVJL04a1+uokfYG5pLUBq9JuGPbAvkTx4zUn0DMZMkxWdeL/EVcbd391LGBo fql5w/FwneMHsQh9JNtIjSc9UwxRObuehXJS2g91EXKAitJ4cbB76IKjg/ZmUd84aF9C hHrQnfpt+yBAE5ZzUn0c0/KDur+tFMoqHmHSlHgx9cnwGnO54MZ06ZiyXk00dWdc1OjN utThpjJ9OiBw99uo5EWIS/4Kugqp2LRkWlLgNJLnBlRROUsMfdQIavWqaCSdyN1HmdSb UPPBDpmugCrj4sMbkoOWSVha+Gi11IBzc3ZWiWcLfiRDy05JsfeN25VV85IP1S2NMFcG o22w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5P2Rj5Xwy+anik/zY/xl7XSVN23ef3NJZYuLPnVj1mI=; b=ftaZzsUQ6TblTZsfYxBVc3oS31xukyvG9pB9Bj1RMd65ra7TXq4KN/re1wf9oyvrD4 Q887sXEiSM9rxaZA+JmnTlArpHfVo5dbn1nLx+ON6fZdubxdbTGS4767nVh0KVH9kpLB 8jvKrJ8oGAAJFcj3zzw+7Go5dQCYLchCM8bLrp/zz7YAOoH2z38z+kJr7qte0knJ8zMS pG7/qUHr+aZrlOpvkdwBSeYzbTv/Kas/NJwBuv5szXKBM7g3VzSLHVL5fvCzv8lqgh7E klFDAf5/cApe5FRFgsW3G3jVtmdkFfXyPc3Ix0bVcXR99NwKcNGt8fEP9zVBJj8iMm6q BHZA==
X-Gm-Message-State: APjAAAXk/EqASaTzsd1v8+6gm3zPNu/0kd2Lg9R8/2FOpc1tm15T88+u cfagrcgrYHAjMsrrg0EuxXx8tk3by5+k92f+Qq8=
X-Google-Smtp-Source: APXvYqzSBmvDgs2k1h25pV8qZTO6QMlRH7Sfdyk4/nbZr7q0D0x77wJ5d2NLDlJGAwvTQ3wZ+T0jrV5e60uimtO+0C4=
X-Received: by 2002:a02:9345:: with SMTP id e5mr58441005jah.29.1555450898282; Tue, 16 Apr 2019 14:41:38 -0700 (PDT)
MIME-Version: 1.0
References: <BL0PR11MB3394FF7694072543BA49ECAC90240@BL0PR11MB3394.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB3394FF7694072543BA49ECAC90240@BL0PR11MB3394.namprd11.prod.outlook.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 16 Apr 2019 14:41:11 -0700
Message-ID: <CA+9kkMA2HFJ1TsBu9vNRrJKraKhf0-c-qMhdBCsu+Q58hwUieQ@mail.gmail.com>
To: "Border, John" <John.Border@hughes.com>
Cc: "etosat@ietf.org" <etosat@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041fe750586aca25e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/WFlRaeYd_JeKdFIdPV6Tgu25quo>
Subject: Re: [EToSat] QUIC ACK Strategy
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2019 21:41:43 -0000

You might want to take a look at
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#page-6

The baseline is this:

    As an optimization, a receiver MAY process multiple packets before
   sending any ACK frames in response.  In this case the receiver can
   determine whether an immediate or delayed acknowledgement should be
   generated after processing incoming packets.


There are specific conditions which are ack-eliciting, but you are
generally permitted to optimize this.

Ted

On Tue, Apr 16, 2019 at 2:11 PM Border, John <John.Border@hughes.com> wrote:

>
>
>     We were looking at some gQUIC traces and noticed an ACK every other
> packet similar to TCP.  Does anyone know if iQUIC includes being able to
> tune the ACK rate?  At very high speeds, that is a lot of ACK traffic…
>
>
>
>
>
> John
>
>
> _______________________________________________
> EToSat mailing list
> EToSat@ietf.org
> https://www.ietf.org/mailman/listinfo/etosat
>

v2.23.0 | Report a Bug | By Email