Re: [tcpm] draft-ietf-tcpm-urgent-data-06
Jari Arkko <jari.arkko@piuha.net> Fri, 15 October 2010 21:02 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA863A6CEF for <tcpm@core3.amsl.com>; Fri, 15 Oct 2010 14:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.443
X-Spam-Level:
X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klhQ3Q9MBO63 for <tcpm@core3.amsl.com>; Fri, 15 Oct 2010 14:02:56 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DF7123A6BCC for <tcpm@ietf.org>; Fri, 15 Oct 2010 14:02:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 763DF2CC31; Sat, 16 Oct 2010 00:04:16 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOLQipFGZiG9; Sat, 16 Oct 2010 00:04:15 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BA76A2CC2F; Sat, 16 Oct 2010 00:04:15 +0300 (EEST)
Message-ID: <4CB8C1CF.1020106@piuha.net>
Date: Sat, 16 Oct 2010 00:04:15 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <FCF0200B-A1AF-4902-A110-D7EC08C39FEC@nokia.com> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <C304DB494AC0C04C87C6A6E2FF5603DB481FB1C732@NDJSSCC01.ndc.nasa.gov> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu>
In-Reply-To: <4CB48DCE.7010606@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: David Borman <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 15 Oct 2010 21:02:57 -0000
All, We discussed this yesterday in the IESG conference call. I would like to summarize my thinking about it and suggest a way forward. (There are a few other ADs who have similar but perhaps not exactly the same thoughts, but I'm the one who representing these thoughts with the Discuss.) The main concern is that at least in my view, urgent data seems pretty badly broken. It has potential interop problems if out of band mode is used, mismatch of recommendations wrt real world implementations that mostly use out of band mode as the default, etc. As far as I understand, when out of band mode is used the two end points have to agree about the semantics of the urgent pointer. It is reassuring that most implementations that you tested actually use the same semantics, but we an implementation that we do not know about or a middlebox could disrupt an application's understanding of the correct order and place of TCP data from the other end. With this background, I felt that the document stopped short of making clear enough recommendations about the use of this feature. In the IESG we talked about what the right level of "health warning" should be, and there were different opinions ranging from text at the beginning of the document to formal deprecation of the feature. I have a proposal below that takes the warning text approach. Note that I'm not really changing anything substantive from what the document was already saying, but if we publish a new RFC on urgent indications, it seems reasonable to make it very clear that there are issues. If these changes were made to the document I would be happy to clear my Discuss, though I do know that Ron would probably would like to see an even more drastic action. What does the working group think? Jari Change Abstract: OLD: This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. NEW: This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet and recommends against the use of the urgent indications (but provides advice to applications in case that they do). Change Introduction: OLD: This document analyzes how some current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect the processing of urgent indications by hosts. This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 [RFC1122] such that they accommodate current practice in processing TCP urgent indications, provides advice to applications using the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. NEW: This document analyzes how some current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect the processing of urgent indications by hosts. This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 [RFC1122] such that they accommodate current practice in processing TCP urgent indications, provides advice to applications using the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. Given the above issues and potential interoperability issues with respect to the currently common default mode operation, it is strongly recommended that applications do not employ urgent indications. Nevertheless, urgent indications are still retained as a mandatory part of the TCP protocol to support the few legacy applications that employ them. However, it is expected that even these applications will have difficulties in environments with middle-boxes.
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Fernando Gont
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Fernando Gont
- [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Peter Saint-Andre
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 John Heffner
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 David Borman
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Anantha Ramaiah (ananth)
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Fernando Gont
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 David Borman
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Lars Eggert
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Jari Arkko
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Alfred Hönes
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Lars Eggert
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Lars Eggert
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Fernando Gont
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Lars Eggert
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 David Borman
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Jari Arkko
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Peter Saint-Andre
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 David Borman
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Jari Arkko
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Jari Arkko
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Ronald Bonica
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 David Borman
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Joe Touch
- Re: [tcpm] draft-ietf-tcpm-urgent-data-06 Jari Arkko