[tcpm] [Errata Verified] RFC7413 (5373)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 14 June 2018 13:15 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61149130E1C; Thu, 14 Jun 2018 06:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HuCY0HslXSzh; Thu, 14 Jun 2018 06:15:00 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D10C130DEF; Thu, 14 Jun 2018 06:15:00 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 18CC0B81BBD; Thu, 14 Jun 2018 06:14:58 -0700 (PDT)
To: vladnc@gmail.com, ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ietf@kuehlewind.net, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180614131458.18CC0B81BBD@rfc-editor.org>
Date: Thu, 14 Jun 2018 06:14:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/zCLNVbJEnh0fT6BrPTvCOKPsJj8>
Subject: [tcpm] [Errata Verified] RFC7413 (5373)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2018 13:15:03 -0000
The following errata report has been verified for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5373 -------------------------------------- Status: Verified Type: Technical Reported by: Vladimir Nicolici <vladnc@gmail.com> Date Reported: 2018-05-31 Verified by: Mirja Kühlewind (IESG) Section: 4.1.3.1. Original Text ------------- For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and ports) at least temporarily. Corrected Text -------------- For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and the destination port) at least temporarily. Notes ----- The original language seems to imply that the cached negative response should only affect connections if they are initiated from the same source port and source IP. Since the client source port can change for subsequent TCP connections, and it's unlikely that just changing the source port would result in a successful TCP FO connection when a previous connection from a different source port failed, associating the cached negative response with the source port is probably not very useful, and could actually be detrimental to performance and reliability, depending on the implementation. If the implementation would decide to check the source port when matching negative cached responses to a new connection, it would negatively impact performance when the source port changes, because the implementation wouldn't find a matching negative response in the cache. Furthermore, if each connection retry is made from a different source port, checking the source port when matching the cached negative responses would make the client unable to connect to the server, until all possible source ports are included in cached negative responses. This means it's much better not recommending to associate the source port to the cached negative responses, to prevent any confusion and possible implementation issues. Either that, or add additional clarification, describing exactly how a negative cached response should be matched to a subsequent connection attempt. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG
- [tcpm] [Errata Verified] RFC7413 (5373) RFC Errata System