Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud

Christian Huitema <huitema@huitema.net> Fri, 15 May 2020 17:39 UTC

Return-Path: <huitema@huitema.net>
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 975793A0F9F for <quic@ietfa.amsl.com>; Fri, 15 May 2020 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L4=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 FW110XidU1QK for <quic@ietfa.amsl.com>; Fri, 15 May 2020 10:39:40 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084333A0F9C for <quic@ietf.org>; Fri, 15 May 2020 10:39:38 -0700 (PDT)
Received: from xse435.mail2web.com ([66.113.197.181] helo=xse.mail2web.com) by mx147.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jZeIy-000ziA-Af for quic@ietf.org; Fri, 15 May 2020 19:39:33 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49NwS530nWzBpS for <quic@ietf.org>; Fri, 15 May 2020 10:31:17 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jZeB3-0004KQ-A3 for quic@ietf.org; Fri, 15 May 2020 10:31:17 -0700
Received: (qmail 32145 invoked from network); 15 May 2020 17:31:16 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.109]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org>; 15 May 2020 17:31:16 -0000
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "tuexen@fh-muenster.de" <tuexen@fh-muenster.de>
Cc: "quic@ietf.org" <quic@ietf.org>, "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" <draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org>
References: <HE1PR0702MB3772606AA3C6D808992C5DF595BE0@HE1PR0702MB3772.eurprd07.prod.outlook.com> <CAM4esxRZBehUOHpEg6E_p7bvY8CpK4oya7rfv4JVTkmAKfQ7jw@mail.gmail.com> <2643A40F-F0DC-45FF-A780-975D5568BE5B@fh-muenster.de> <03b92d83-b3f9-2fb3-c21c-5bf3fda767cb@erg.abdn.ac.uk> <425504a704c5b5ee6ea71fd23e9490cf8d79251a.camel@ericsson.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Subject: Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud
Message-ID: <5aaaaaa7-92c1-a4bf-921c-08d476b46fdc@huitema.net>
Date: Fri, 15 May 2020 10:31:17 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <425504a704c5b5ee6ea71fd23e9490cf8d79251a.camel@ericsson.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.197.181
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0RZ/HtDapBdRUZhgsSk2AkqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftKP0w8txmrUrOsodeV+sfCU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/GLPGseHORnR7zfibQ2DIPryme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ileOfMnQTuxRu w7b3K/aRb5idZCY0qG6Fj3aEzDHI1tEvuvL2XBW+TZ43EfLFA0/zVppAsDwSmLLjI7Hj98S4eAl8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVLXMAeAMbRFc86R noqT1OeMY4NhlpOo+XFzBzK20cyXxkge2kTMxWW+Pmu2Yxsc0+YVC4aMwsnMYQ35odEttNdOXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdifDd38tBP0TUtnaiMpAROl1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yDQrdDNqGjBCEJ8ZYOJvNSHAXH0>
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: Fri, 15 May 2020 17:39:42 -0000

On 5/15/2020 8:56 AM, Magnus Westerlund wrote:
> Hi,
>
> So what Gorry says appear correct. And it is a constant but its value could in
> worst case be not only interface but actually path dependent. The reason being
> that if the lower layers adds headers in specific cases. 
>
> Although use of IPv6 extension headers are not problem free there might be cases
> where such a header is added for some paths but not others. Thus, specifying the
> MIN_PLPMTU correctly to be stable acrosss interfaces and paths could be
> problematic. But for QUIC as Gorry says the stake is already in the ground and
> it is in fact reasonable maybe to be more precise to say that a default
> MIN_PLPMTU to use can be 1200 bytes as we don't expect QUIC to work over paths
> that don't support this. 

Quic servers will only accept an Initial packet if it is at least 1200
bytes long. This pretty much enforces a min MTU requirement of 1200
bytes. Quic will not work on a network path does not support that.

> We might get some interesting questions on the padded handshake packets when
> some want to run QUIC as IOT transport over radios such as what LPWAN WG
> discusses where it is very costly to send 1200 bytes packets. The radio blocks
> are more in the range of 32-64 bytes if I remember correctly. 

It is pretty hard to design an end-to-end transport that works well with
a very small end-to-end MTU. There are just too many trade-offs. For
example, the 1200 minimum MTU in Quic was chosen to mitigate DDOS
attacks. That's the kind of trade-off mandated by the requirement to
work end-to-end over the Internet. I assume that IOT devices with
limited networking capability will also have limited connectivity, for
example to a local relay.

>
> So I think this discussion is pointing to that we should actually move Section
> 6.3 from draft-ietf-tsvwg-datagram-plpmtud into draft-ietf-quic-transport so
> that the details can still be polished. 

I am comparing the specification in the paper with my early
implementation of PMTU discovery in Quic (Picoquic). They are pretty
much aligned, except for one important point regarding the sending of
probes. As the draft says, the Picoquic implementation will send probes
to discover the Path MTU, "by selecting step sizes from a table of
common PMTU sizes". But there is an additional step in the Picoquic
algorithm, a decision to probe or not as a trade-off between potential
gains in efficiency and potential costs in probing.

End-to-end probes consume resource. Sending a 1500 bytes probe consumes
about the same resource as sending 1500 bytes of data using the already
discovered packet size. Nodes send such probes because they expect a
gain in efficiency. If they discover that MTU size is 1500 bytes instead
of 1200 bytes, they can send a 1.5 MB file in 1000 packets instead of
1250. There will be 25% fewer packet headers, 25% fewer packet
processing, 25% fewer packet acknowledgements. That seems "worth the
try". But these gains depends on how many bytes the nodes expect to send
during the course of the connection.

Suppose now that instead of 1.5MB of data the node only anticipates
sending 15KB. Successful probe means sending 10 packets of 1500 bytes
instead of 13 packets of 1200 bytes. The typical overhead per Quic
packet would be about 60 bytes, between link header, IPv6 header, UDP
header and Quic header. Sending larger packets will save 180 bytes in
packet overhead, which is less than the 1500 bytes of sending a probe.
The node will achieve better throughput by not bothering with PMTU probes.

Of course, the numbers in the examples above are arbitrary. But there is
a principle there: at a given time, nodes send probes because they
anticipate a gain in efficiency over the reminder of the connection, if
the probe is successful. This gives us a simple test: only send probes
if the anticipated gain is larger than the cost of sending the probe:

    if (anticipated_gain * probability_of_success > cost-of_probe)

        then: send probe

        else: keep current MTU

That inequality informs the decision to send a probe or not. For
example, suppose that discovery so far has assessed that the PMTU is at
least 1400 bytes but lower than 1500. The table of step sizes says that
the most likely value between 1400 and 1500 is 1430. Is it a good idea
to try 1430? Maybe, but the efficiency gain will be just over 2%. In
case of success, the cost of probing will only be amortized after
sending 50 packets. If the probability of success is about 50%, the node
should only send the probe if it anticipates sending at least 100 packets.

The inequality also informs the decision of which probe to send. For
example, assume that the discovery so far has assessed that PMTU is at
least 1200 bytes. Will the node probe for 1500 bytes or 1400 bytes? To
make the decision, the node can assess the potential gains and the
probability of success. 1400 bytes might be a safer bet if the node
anticipates just sending a small amount of data, 1500 would provide a
higher gain if the node anticipates sending a large amount. Trying 8K
might be even more attractive if both peers support that size, as the
lower probability of success is compensated by a much higher gain.

The inequality also informs the decision on whether to repeat a probe.
Suppose that a node tried a 1500 bytes probe and failed. There are two
explanations: either the path MTU is lower than 1500 bytes, or the probe
was lost for other reasons. Applying Bayesian logic, the node can
reevaluate the probability of success of a 1500 bytes probe. It may well
be that sending a 1400 bytes probe will now be more interesting than
trying 1500 bytes again.

It may be that this discussion is too much detail for the plpmtud draft.
I could of course submit a draft discussing the probabilistic approach
to PMTUD. But it still might be a good idea to add a general
consideration in the description of the algorithm, asking implementation
to take into account probability of success and expected gains before
sending a probe.

-- Christian Huitema