Re: PADDING vs PING

Martin Thomson <martin.thomson@gmail.com> Mon, 19 March 2018 14:36 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88CD1241F3 for <quic@ietfa.amsl.com>; Mon, 19 Mar 2018 07:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 NWUcnBvDHQCi for <quic@ietfa.amsl.com>; Mon, 19 Mar 2018 07:36:41 -0700 (PDT)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 5E2CA12D870 for <quic@ietf.org>; Mon, 19 Mar 2018 07:36:41 -0700 (PDT)
Received: by mail-ot0-x22f.google.com with SMTP id y11-v6so17600545otg.0 for <quic@ietf.org>; Mon, 19 Mar 2018 07:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wVwjNLcHcbwCNthvDqHR/BJ30FlWc7VJQ5tkncYywbU=; b=GwZIlq1FnXZtNWxMjt2ePkRnK+5joaMlRxKQrl8a/0JiJYIZXSRNlaFyD9jrqe0pLd IyXZ8TwMstTLwS7/H/HKA9cNlTEUyTIUdO6Mddf2jK/q5SpnckUQEZVNpUiFmQErkh51 lhekfsBC8k/DQkvd8w0w7nJgP2ZAm52GcInOxhoBtEkEy+FdviyDOpXpDddJpMkRV2jO z1PiRGeUrpePL3ou25yO0+FlbzR0APQZGIh1y/hbaHF8Ei9Aj4Xz0V1qhiR+lqtNUnUn rK266AbSa9wQt4Dwd0YhhBnFfVkN5uC43vczO9LPPqtFYLCUsjKw0SsYrT+SbWSCX/V6 RiDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wVwjNLcHcbwCNthvDqHR/BJ30FlWc7VJQ5tkncYywbU=; b=iIpKvRhYO5naw9eh/3J0NDtJJXAAI8FjXtkTY6d2sVLd6fOlOOpis+RbnMcJl545tP 1+upo9e9rucK+XQGmWGelcGLxAd7Cbv09r53MTo/1HSLq6X7bqHi9JnYczQQLozbq4b3 3j/gDD/Lw9xusHqnDexVD56VVWBrfPKNnkcVlOANOOOiXlqVdDntfV0RLURiAU6ORvD+ 9qO1l/pgaiOu8NosO+K5LEzQ8CFfZ1YUAErEXlFS6mWDVVQJwNKuBUp89qlyLEn1FWwu wF0FivJp02nGpWKeLI5e4hacXSzt3kRnX0gEXsOkMuU4+d+HRx53hs+C0dpIX8B8GL9u 8iwQ==
X-Gm-Message-State: AElRT7Gf+6TZJjGSSkz5YQ7wRD93ORzxdXpSreOHdTc/s+x6qo3hhgF9 1AXpjkFlhJ/CkGAPzSg8CIgJ/MOREhvOTUVcVVahyA==
X-Google-Smtp-Source: AG47ELtdXKTqP2cwxnOMVOof6fxomdwX1iJeV5Nr7aryD+hSNsQOf3HBDxsrIh+qA5RZWsrxaXo4KHDL6nBJon5QwMk=
X-Received: by 2002:a9d:350a:: with SMTP id o10-v6mr7499021otc.283.1521470200511; Mon, 19 Mar 2018 07:36:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Mon, 19 Mar 2018 07:36:40 -0700 (PDT)
In-Reply-To: <0a5ec245895043f196c0e93026d8e7ea@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <0a5ec245895043f196c0e93026d8e7ea@ustx2ex-dag1mb5.msg.corp.akamai.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 19 Mar 2018 14:36:40 +0000
Message-ID: <CABkgnnU5FDgfhkGybBAV4Ei=cB7E6KF-WbVDgOm=w9pV51=gLA@mail.gmail.com>
Subject: Re: PADDING vs PING
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LIG1SUueKdpj4j0uk3wFiug1ySk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2018 14:36:43 -0000

The current text counts ACK towards bytes in flight when there are
other frames present, so you just described Option 2.  Albeit more
precisely.

The key is that packets that comprise only (ACK[, PADDING]) count
toward bytes in flight.  That is, the packet counts or not, but the
content determines the answer.

On Mon, Mar 19, 2018 at 2:23 PM, Lubashev, Igor
<ilubashe=40akamai.com@dmarc.ietf.org> wrote:
> Since 4 proposals is not enough, let me propose the 5th one, which is an
> extension of Subodh’s proposal.
>
>
>
> PADDING does NOT count for bytes-in-flight (and does not require ACKs) when
> it is a part of ACK+PADDING packets.
> PADDING does count for bytes-in-flight and does require ACKs otherwise
> (including in PADDING-only packets).
> The difference between PADDING and PING in non-(ACK+PADDING) packets is that
> PING requires an ACK to be sent ASAP, while ACKing PADDING can be delayed,
> if the receiver does some ACK coalescing.
>
>
>
> Igor