[tcpm] [Technical Errata Reported] RFC7413 (5373)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 31 May 2018 14:24 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 58CF612EC9D for <tcpm@ietfa.amsl.com>; Thu, 31 May 2018 07:24:21 -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 4a05I1FF1B8g for <tcpm@ietfa.amsl.com>; Thu, 31 May 2018 07:24:19 -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 A087D12E044 for <tcpm@ietf.org>; Thu, 31 May 2018 07:24:17 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B5ED7B825CF; Thu, 31 May 2018 07:23:55 -0700 (PDT)
To: ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, michael.scharf@nokia.com, tuexen@fh-muenster.de, nishida@sfc.wide.ad.jp
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: vladnc@gmail.com, tcpm@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180531142355.B5ED7B825CF@rfc-editor.org>
Date: Thu, 31 May 2018 07:23:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/iPIo9Bsmu_atjYQt-pDjClXbpdE>
X-Mailman-Approved-At: Thu, 31 May 2018 08:17:20 -0700
Subject: [tcpm] [Technical Errata Reported] RFC7413 (5373)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
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, 31 May 2018 14:24:28 -0000
The following errata report has been submitted for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5373 -------------------------------------- Type: Technical Reported by: Vladimir Nicolici <vladnc@gmail.com> 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- 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] [Technical Errata Reported] RFC7413 (5373) RFC Errata System
- Re: [tcpm] [Technical Errata Reported] RFC7413 (5… Yuchung Cheng