[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