Re: [tsvwg] Review: draft-ietf-datagram-plpmtud-12

Martin Duke <martin.h.duke@gmail.com> Tue, 10 December 2019 16:20 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589DF12010D for <tsvwg@ietfa.amsl.com>; Tue, 10 Dec 2019 08:20:59 -0800 (PST)
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 8Mf3gNr3iufa for <tsvwg@ietfa.amsl.com>; Tue, 10 Dec 2019 08:20:57 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 6F12A120100 for <tsvwg@ietf.org>; Tue, 10 Dec 2019 08:20:57 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id t14so3852352wmi.5 for <tsvwg@ietf.org>; Tue, 10 Dec 2019 08:20:57 -0800 (PST)
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=qLBbduvEXBD+Xs+6mzkiTwwr4RSACNKA4A9WywI75cI=; b=erIpFMPFXeRzw7FCNK7aNDIu7g6LrhhKLcGwKOTpB0pz3O+ZTuC8gmI4xEN3iEjyFV nYGRBa+YBSoHTnJchQW+jMAUXq4h5marq85EXjNw6N49oqoxDW9ons3Hl0cCLRBlgEFx VoAGB4OgfJSLrkT623WH26duu0djhdSotiij6W4S5irCH2E4F6Ifh6rciJD012U2tjdg zmE+OoWyQuULYC5OTGL14xoUKkQ3owoCKTA7gT5KD37OTFyhhz+T4xuzHX2FgXxOaauj uSR+pfVDvc9PVBTyntugqn9gXoTo4e7oL0mwtvfSAWFnkhOm3uYLRjngKOIOpTk2K5hr 5qPQ==
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=qLBbduvEXBD+Xs+6mzkiTwwr4RSACNKA4A9WywI75cI=; b=MamR7agkymjlxcLpUMSlNcJNxq7sbEBQbi0pXBNsnL/htAkr8O2sDZlCocREoZLoGn Gd7xgiDl0CAawfi5F9VS0JQXiNacx8G7olgKnuU8ZKjlX8C8ihdUMoHdwMNTw9UYkbT/ /Yy2qnuL8QkU7DVPk3jTSa/vrjMpQ4SFS7GUJ6wWKOhOj1JkoQKu3CZc2t7N0UHSDtae FyJo55E8lYkN2oNfoQPCLeu4zwg7yWoyYD1sSX5EDpwOhB+wYwcgYM6t9im4+c7lTo9o e2NXNAWfckqp+ayCV+fD2R/nTmrPc76JRwWnmjMqVVCJGMdbXJX1nXcPhGVExyk+bUWf BSDw==
X-Gm-Message-State: APjAAAWPRAriC245BCfS/cX9K24MSukI5GVFYvm0NCAA99pUAsqgtytL VcrFv/SzmJk6OzO/FazqFrUeySPJfPo4GiX/rvh1TA==
X-Google-Smtp-Source: APXvYqxFICHz/BDY3GNoazaTSowFOtgOzjxYzeycJBsjANpkq6CXwJdP65pw3yAsir1F52BFm7mjXBfzCFUUWzhSDxo=
X-Received: by 2002:a1c:9958:: with SMTP id b85mr6345501wme.63.1575994855795; Tue, 10 Dec 2019 08:20:55 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxT8KqeWjcfL4FSH3g_VFs8N492+cpxuKEm_kFb6-2wpxw@mail.gmail.com> <5B26F333-57D3-4A86-8279-BC82266F07D7@lurchi.franken.de> <CAM4esxSfT28WsOiYAEq8BH7y1cnxe4SDyP-fcjDrckpo0EAR+g@mail.gmail.com> <5DECB66C.5080906@erg.abdn.ac.uk> <CAM4esxSAy0w2ey6kCa8EnVq3DBwzL-fTSS60HLvXdcQjQfvkNQ@mail.gmail.com> <3441bc2b-c062-53ec-068f-16d174bd54b2@erg.abdn.ac.uk>
In-Reply-To: <3441bc2b-c062-53ec-068f-16d174bd54b2@erg.abdn.ac.uk>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 10 Dec 2019 08:20:44 -0800
Message-ID: <CAM4esxT3LKMuO3frqbBQuWjvJkFryoOF8_6ETC4Ta5fqVBhO9g@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c324705995be543"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yBaPZWopl7g21wY4xOL6Pxq5BjA>
Subject: Re: [tsvwg] Review: draft-ietf-datagram-plpmtud-12
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 16:20:59 -0000

On Tue, Dec 10, 2019 at 4:42 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
wrote:

> Thanks Martin - I think I am starting to understand you issue, so please
> check below:
>
> On 09/12/2019 18:16, Martin Duke wrote:
>
>
<snip>


> >
> > I think this reply conflates three questions that need not be unified:
> > 1) Are Probe packets counted against flightsize?
> > 2) Are Probe packet losses treated as congestion signals?
>
> So, do you mean that (1) a sender COULD use cwnd to determine whether to
> probe (i.e. only
>
> probe if flight size allows), actually I am OK discounting them from
> this limit
>
> providing they are as infrequent as specified in DPLPMTUD - but I would
> mind if a design
>
> wanted to be a little more conservative. If I understand, this is about
> when to probe.
>
> but (2) but the sender needs to still should realise that attempts to
> raise the PMTU
>
> are likely to fail, so you shouldn't count loss of a probe as
> congestion, which is what
>
> section 3, requirement 7 was about.
>

I *think* we are in agreement that it is permissible but not required to
ignore cwnd when sending probles. It would be nice for this to be in the
general guidelines of the draft rather than just the SCTP-specific section.


>
> > 3) Under what circumstances do probe losses indicate that the packet
> > is too big?
> >
> That can be clarified - PLPMTU is reduced only when PROBE_COUNT>MAX_PROBES,
>
> so never for an isolated loss.
>

I've read 4821 a little more carefully and withdraw this objection. I see
now that 4821 takes a single probe loss, if not accompanied by non-probe
loss, as an MTU signal, whereas DPLPMTUD requires *multiple* probe losses
without reference to non-probe losses. Now that I understand the status
quo, this seems reasonably robust. Sorry for the misdirection.


>
> > IMO these design decisions can be completely independent -- they
> > certainly are in our QUIC code, which uses a bastardized version of
> > PLPMTUD.
> >
> > For #1, as I replied to Michael, the SCTP section is doing the right
> > thing but I would like general advice for other congestion controls to
> > not count probes at all. At the moment the QUIC spec suggests that
> > probes would count against flightsize.
> >
> See if I understood above?
>

Yes

To summarize, other than general guidance about ignoring CWND I now have no
design issues -- just the nits in my original email.