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.