Re: kMaxDatagramSize
Jana Iyengar <jri.ietf@gmail.com> Tue, 17 September 2019 01:09 UTC
Return-Path: <jri.ietf@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 000E81200D6 for <quic@ietfa.amsl.com>; Mon, 16 Sep 2019 18:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 quCpFHOJOI5Z for <quic@ietfa.amsl.com>; Mon, 16 Sep 2019 18:09:46 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B6B09120144 for <quic@ietf.org>; Mon, 16 Sep 2019 18:09:45 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id 72so1442623lfh.6 for <quic@ietf.org>; Mon, 16 Sep 2019 18:09:45 -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=ccxDqH2Vxd8hBAwS7M9Gyta4XJ/rVHT917JHW9UlkUw=; b=NaH/WVm3vUK2XrAeObaztsz9RWpjerWMhZfJxGnHvnQG9pPE9FxMYL3kuMT4khbWeK aIZ//6f9EhEq7EIawjsMN3i1n4eDu8pDAKX4yVSd8ZMuy92uCIqzG59YEUqjOSX1IAhE bSxmlQaPUklmocnGwdBVCofb5db/vtP1jM1/W3c45JTJqE8fIaVV0Il00j352iYV5YYm 3yczER+UyLn3sEC+ikb7YA+SDMvCJu1l4VsZ6sd8NHvZ4rVWYLWM3Rn15oDSATB2iqdA 1C4W3XOj4HrHDG6swwjENnXm/HXu2Ld+p+5D+ryXjQk8xBJr7wfSly+edtDT5I+PVsQl MSBg==
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=ccxDqH2Vxd8hBAwS7M9Gyta4XJ/rVHT917JHW9UlkUw=; b=tn2KIrLHcXmXvmftgAiWsjuA26Gt3+Goyv0vyIuxhO/qwuyfN7hzhVq4Cm2keuxpdg oleAHLhU2epdBKeNtI5CjZuoHVYp6Htz3hmpcOWP6UgUxwcpo1Sjpl2BKtUojZLghAY1 XGmN8QHL34NGsl3XXQp2ULy3Jhl1oIiGkWB/q571ciAP5LWfZirx8uNV05USw3NtgbAA cTmJvJMXB16Z4ZYBepW/vVvGjjx0pitU9X4UC7Y8VDlEbut/JyHOwqkYxgG9E/eCHYNB AIA2wbk4hM+ns+8QRmI1Uv68m0wuDxC3VGfnW3r0IZj/1VA5UU411anrFkjib3tg1pUH CZcA==
X-Gm-Message-State: APjAAAUztHZqiC0L5SUq1eg0JHsQYj0dml1NDdcz5j+AWHT9eVd4lb3k QXo7sM+MOdUpJXT4j1CawSKGxl6gh7CmWf8cl+A=
X-Google-Smtp-Source: APXvYqxnDk1eWYxa9v4wkZodqcYt41bBZWWqljZVokNV+qPqVFjjB9nL/+tzqp1JTZm965eC7z4aaBcMms/7YelzeHs=
X-Received: by 2002:ac2:554e:: with SMTP id l14mr604830lfk.32.1568682583978; Mon, 16 Sep 2019 18:09:43 -0700 (PDT)
MIME-Version: 1.0
References: <08A80917-B4B7-49B2-8695-790AFFC6866C@fh-muenster.de> <CAKcm_gPqhPdyHeg9S38yU4sZo9AeqXppVbryDMCUWDcBFECUmA@mail.gmail.com>
In-Reply-To: <CAKcm_gPqhPdyHeg9S38yU4sZo9AeqXppVbryDMCUWDcBFECUmA@mail.gmail.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Mon, 16 Sep 2019 18:09:33 -0700
Message-ID: <CACpbDcfXnnrmzM4nNJTgZWrC9H+jUoLnMdo-kktx1Qo+t54PDQ@mail.gmail.com>
Subject: Re: kMaxDatagramSize
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: Timo Völker <timo.voelker@fh-muenster.de>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002f03e00592b560fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/idb9Vv9pnYlk22ZGiDsjJQRxM1Q>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 17 Sep 2019 01:09:48 -0000
Yes, this should be changed to reflect the actual connection's max packet size. We use this in congestion avoidance, which will be slower when the value here is smaller than the actual max packet size. I've filed https://github.com/quicwg/base-drafts/issues/3041. On Mon, Sep 16, 2019 at 2:01 PM Ian Swett <ianswett= 40google.com@dmarc.ietf.org> wrote: > In recovery, kMaxDatagramSize is used for initial congestion window, > initial congestion windows, and the growth rate of Reno. > > As you state above, it's expected most connections will have a value > larger than 1200. Possibly a recommendation of >= 1200 bytes would make > more sense? > > On Mon, Sep 16, 2019 at 2:10 AM Timo Völker <timo.voelker@fh-muenster.de> > wrote: > >> Hi, >> >> I wonder why kMaxDatagramSize is a constant and why the recommended value >> is 1200 (section B.1. of the recovery draft). >> >> The transport draft mentions PMTUD, which makes the QUIC maximum packet >> size variable. >> Also it mentions that, in absence of a PMTUD, we can assume a QUIC >> maximum packet size of 1232 or 1252 for IPv6 or IPv4, respectively. Why is >> 1200 bytes recommended then? >> >> My assumption is that kMaxDatagramSize = QUIC maximum packet size. Is >> this just wrong? Is it OK to use a kMaxDatagramSize with kMaxDatagramSize >> <= QUIC maximum packet size? >> >> Thanks, >> >> Timo > >
- kMaxDatagramSize Timo Völker
- Re: kMaxDatagramSize Ian Swett
- Re: kMaxDatagramSize Jana Iyengar