Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
David Borman <david.borman@windriver.com> Tue, 28 October 2008 05:43 UTC
Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349B83A6979; Mon, 27 Oct 2008 22:43:12 -0700 (PDT)
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 C6E1C3A6979 for <tcpm@core3.amsl.com>; Mon, 27 Oct 2008 22:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.76
X-Spam-Level:
X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1]
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 h23oPG4Q3BsD for <tcpm@core3.amsl.com>; Mon, 27 Oct 2008 22:43:10 -0700 (PDT)
Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id AD6D63A68B9 for <tcpm@ietf.org>; Mon, 27 Oct 2008 22:43:10 -0700 (PDT)
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m9S5gutC024775; Mon, 27 Oct 2008 22:42:56 -0700 (PDT)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 22:42:56 -0700
Received: from [147.11.4.189] ([147.11.4.189]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 22:42:55 -0700
Message-Id: <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com>
From: David Borman <david.borman@windriver.com>
To: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <200810280203.m9S23foZ023071@venus.xmundo.net>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 28 Oct 2008 00:42:55 -0500
References: <200810280000.m9S00h4E029878@venus.xmundo.net> <A56C813C-B46D-4A02-A905-DD6B7E163156@windriver.com> <200810280203.m9S23foZ023071@venus.xmundo.net>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 28 Oct 2008 05:42:56.0180 (UTC) FILETIME=[07296740:01C938C0]
Cc: tcpm@ietf.org, ayourtch@cisco.com
Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
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: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org
On Oct 27, 2008, at 8:58 PM, Fernando Gont wrote: > Hello, David, > > Thanks for your timely response. You'll find my comments inline.... > > >> First, despite what 793 and 1122 say, TCP does *not* have urgent data >> in the sense that people think. TCP has an urgent *pointer*, that >> indicates an interesting point in the data stream. *All* the data >> prior to, and including, the Urgent pointer is the urgent data. > > Agreed. However, there are two issues here: > > Firstly, the recv(2) with MSG_OOB only returns a single byt of > urgent data, whereas according to your explanation it should return > all data prior to, and including, the Urgent pointer. No, applications shouldn't be using recv() with MSG_OOB on TCP sockets. That is the interface for the old, broken BSD interpretation of the urgent pointer. TCP does not have out of band data. The SO_OOBINLINE option was added so that new applications (new, circa 1989, the date of RFC 1122) could turn this broken interface off and leave the data in the data stream where it belongs. It was felt that we couldn't just change the BSD TCP implementation to the new behavior, because that would break all the existing applications. With SO_OOBINLINE, applications could switch over without there needing to be a flag day. > Secondly, virtually all implementations intepret that the Urgent > pointer point to the byte following the last byte of urgent data. > And this is what RFC 1122 aims at correcting. (However, this > correction didn't reflect into actual implementations.) > > >> It is >> up to the application to decide what that means, and which data >> relative to the urgent pointer is interesting, but typically it would >> be the data just after the urgent pointer. The application can't say >> "these x bytes of data are the urgent data". > > mmm... why couldn't it say, e.g., that all the bytes up to the > urgent pointer are urgent data? (currently, only the byte before the > Urgent Pointer is interpreted as Urgent data... which does not seem > to agree with what the RFCs specify....) The RFC more or less does say that. The moment you get a packet with the URG bit, you enter urgent mode for all data until you get past the urgent pointer, hence that is all urgent data. The key things are: 1) The urgent pointer only tells you where the urgent data ends 2) Urgent pointers are cumulative, a new urgent pointer updates where you leave urgent mode. 3) The urgent pointer can point beyond the data in the packet in which it is sent. The problem is that (most of) the urgent data, as defined in RFC 793, is typically the uninteresting data. For example, in telnet the urgent data is the data you want to read and flush, until you get to the Telnet Sync command. >> If a TCP data stream writes some data in normal mode and the data >> gets >> lost, then there is a successive write in urgent mode, then when the >> lost packet is re-transmitted it'll now be transmitted with the URG >> bit and the urgent pointer, turning that data into "urgent data" by >> the 793 definition. That's not what people think when they first >> hear >> the term "urgent data", but that's how it works. > > Agreed. > > >> it to the application out-of-band. To fix that, the SO_OOBINLINE >> socket option was introduced, and is still around today. All >> applications that use urgent data should be using the SO_OOBINLINE >> option, there's no excuse for using the old, broken BSD >> interpretation >> about urgent data. > > Well, this seems to be the default for all major TCP implementations > (see our survey). Ok, there are two issues here. First, SO_OOBINLINE turns off the old, broken BSD interpretation that removed a byte of data from the data stream and presented it to the application with the recv()/MSG_OOB call. The second issue is which byte is indicated in the packet with the urgent pointer. If the application knows what the kernel does, it can adjust accordingly so that the correct byte gets marked in the TCP data stream. >> There isn't anything wrong with the 793/1122 definition of the Urgent >> Pointer. > > The specific issue we are discussing is that the Urgent pointer is > defined in RFC 793 as pointing "to the byte following the last byte > of urgent data". RFC 1122 later corrected this definitation, stating > that it points to "the last byte of urgent data". That's why I said 793/1122. RFC 793 defined it both ways, and in RFC 1122 we clarified that the definition on page 56 is correct, and the one on page 17 is wrong. >> It might be useful to clarify the description if people are >> still implementing and/or using it wrong, but the definition in >> 793/1122 is still correct. > > Section 4.2.2.4 of RFC 1122 states: > "The second sentence is in error: the urgent pointer points > to the sequence number of the LAST octet (not LAST+1) in a > sequence of urgent data. The description on page 56 (last > sentence) is correct." > > This is where I'm saying that RFC 1122 differs from RFC 793. Yes, of course. RFC 1122 says that this definition is wrong. In RFC 793 the urgent pointer is also defined on page 56: If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the urgent pointer in the outgoing segments. which conflicts with the definition on page 17. RFC 1122 clarifies that this definition on page 56 is the correct definition. I'll also point out that RFC 961 also says that the definition on page 17 is wrong; RFC 1122 re-enforces what was already documented. I will say that using the recv()/MSG_OOB interface is the bigger issue. You just have to look at the BSD Telnet implementation and the dances that it does if SO_OOBINLINE isn't defined to understand why that broken interface is such a bad idea. -David Borman > > > Thanks! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Fwd: New Version Notification for draft-go… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… David Borman
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Andrew Yourtchenko
- Re: [tcpm] Fwd: New Version Notification for draf… David Borman
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Stefanos Harhalakis
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Andrew Yourtchenko
- Re: [tcpm] Fwd: New Version Notification fordraft… Anantha Ramaiah (ananth)
- Re: [tcpm] Fwd: New Version Notification fordraft… Eddy, Wesley M. (GRC-RCN0)[VZ]
- Re: [tcpm] Fwd: New Version Notification fordraft… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification fordraft… Andrew Yourtchenko
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch