RE: Treatment of ICMP for PMTU

"Lubashev, Igor" <ilubashe@akamai.com> Mon, 02 July 2018 23:20 UTC

Return-Path: <ilubashe@akamai.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 976E21311F1 for <quic@ietfa.amsl.com>; Mon, 2 Jul 2018 16:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 1yhn7O9WsCur for <quic@ietfa.amsl.com>; Mon, 2 Jul 2018 16:19:59 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B5EF2130E8E for <quic@ietf.org>; Mon, 2 Jul 2018 16:19:59 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w62NIBFT022800; Tue, 3 Jul 2018 00:19:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ZFKmSskF2YOPxxNxKz8wGiAm5VqrD1dyHYec/JRzL+0=; b=TRhrLECsb9sZGtfagN6ur+cG3bocLEX/48AP7bo6zd0HBF/WcnjZswaGCVCo+4VAqbkn 6toztfM2DlhzYulYooOFnN40RUqiTWX3RLhkKnFDtGzXw7U8rtzc/33UEb0dW2yYmmf5 E2xW0UjZMj6FgdKnfHL5qbcWLlyYkMBAkQMT+UE4yHYxbgVXY8uPP6QaC5/JVDBbRcG1 SxkJ1eI47jDM16eo02DKby9CIqfheF0v5q5K9gmPoYsHj4iDZSSfcK0iDNhRAjuAgxwQ ewdWXnDNwQhi9Ksu5r8PUcc4sikUW3NnNCsG5G5nhTSS5tXrt3sc6z5dhu9w/56TLyCl Ow==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2jx1grppav-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 00:19:54 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w62NBPva008329; Mon, 2 Jul 2018 19:19:54 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jx56uw0g5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Jul 2018 19:19:53 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 2 Jul 2018 18:19:52 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Mon, 2 Jul 2018 18:19:52 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Eggert, Lars" <lars@netapp.com>
CC: IETF QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Subject: RE: Treatment of ICMP for PMTU
Thread-Topic: Treatment of ICMP for PMTU
Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wAV77aAAAI9IOAA1Pw3gAASjHLQ
Date: Mon, 02 Jul 2018 23:19:51 +0000
Message-ID: <643f80954e6a45ba881c7d4a90a066d0@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com>
In-Reply-To: <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.38.207]
Content-Type: multipart/alternative; boundary="_000_643f80954e6a45ba881c7d4a90a066d0ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807020258
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807020259
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MYVZpCcJV2sp32SML0-0Yd0Bgxg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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, 02 Jul 2018 23:20:05 -0000

  *   Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU.

From my perspective, there are two things that are important here:

  1.  Use PTB signal to start probing (as you said).  This is section 3.3.
  2.  Identify cases, when you can set PMTU to PTB_SIZE immediately upon receipt of PTB, while the probing is happening.

Plus one more thing that is not in that draft at all – I think it is prudent to respect PTB, even if that PTB is not validated (i.e. w/o on-path proof, using my lingo), if PTB_SIZE is large enough (to be defined how large).  It probably deserves its own thread in tsvwg.


  *   Igor


From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Monday, July 02, 2018 4:46 AM
To: Lubashev, Igor <ilubashe@akamai.com>; Eggert, Lars <lars@netapp.com>
Cc: IETF QUIC WG <quic@ietf.org>; Martin Duke <martin.h.duke@gmail.com>
Subject: Re: Treatment of ICMP for PMTU


Hi,

Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor:



 • What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)?



Isn't this sufficiently covered in 4821?



Not really.  Or, at least I could not find anything more useful there then: "If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message."  So 4821 seems silent on what to do if ICMP is received for a non-probe packet, and it seems silent on how one could decide whether to set search_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help here).  These questions are what I am trying to address for QUIC.



4821 uses MAY in the sentence above, since it does not really give any better indication.  This PR draws a distinction between ICMP w/ and w/o on-path proof and in some specific cases, it recommends a SHOULD.




If you look at the updated PLPMTUD:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Ddatagram-2Dplpmtud_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=uDGI9jiS7Geg3dbv7-6X13iWfUICKy3fOiekJYaO_HA&s=MQRhWnsLTgO3sRXM-EnMvYTRoX9HubTysSfT_FPicJk&e=>

3.3.  Reducing the PLPMTU: Confirming Path Characteristics



   If the DPLPMTUD method detects that a packet with the PLPMTU size is

   no supported by the network path, then the DLPMTUD method needs to

   validate the PLPMTU. This can happen when a validated PTB message is

   received, or another event that indicates the network path no longer

   sustains this packet size, such as a loss report from the PL



   All implementations of DPLPMTUD are REQUIRED to provide support that

   reduces the PLPMTU when the actual PMTU supported by a network path

   is less than the PLPMTU.

Section 4.9 says:

   PROBE_DONE: The PROBE_DONE state indicates a successful end to a

      probing phase.  DPLPMTUD remains in this state until either the

      PMTU_RAISE_TIMER expires or a received PTB message is verified.

However, I have to say that the draft is a bit unclear on what to do at this point.

I guess the options are two.

Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU.

I will start a thread on TSVWG WG mailing list regarding the lack of specific text in their draft for this case.

Cheers




Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>

----------------------------------------------------------------------