Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00

Fernando Gont <> Tue, 28 October 2008 02:04 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 84EBA3A6BCD; Mon, 27 Oct 2008 19:04:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 620C03A693F for <>; Mon, 27 Oct 2008 19:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L8K4feRfA5zx for <>; Mon, 27 Oct 2008 19:04:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 185903A694A for <>; Mon, 27 Oct 2008 19:04:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72DF06B657D; Mon, 27 Oct 2008 23:04:03 -0300 (ART)
Received: from ( [] (may be forged)) (authenticated bits=0) by (8.14.1/8.13.8) with ESMTP id m9S23foZ023071; Tue, 28 Oct 2008 00:03:42 -0200
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 27 Oct 2008 22:58:08 -0300
To: David Borman <>
From: Fernando Gont <>
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Mon, 27 Oct 2008 23:04:02 -0300 (ART)
Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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.

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....)

>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.


>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).

>There isn't anything wrong with the 793/1122 definition of the Urgent

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".

>  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 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.


Kind regards,

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

tcpm mailing list