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

Andrew Yourtchenko <> Mon, 10 November 2008 00:47 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 63A7C3A69B3; Sun, 9 Nov 2008 16:47:54 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DBE53A69B3 for <>; Sun, 9 Nov 2008 16:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.605
X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T9niClIz7UnC for <>; Sun, 9 Nov 2008 16:47:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4CB093A6813 for <>; Sun, 9 Nov 2008 16:47:52 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from (localhost []) by (8.11.7p3+Sun/8.11.7) with ESMTP id mAA0lgu00636; Mon, 10 Nov 2008 01:47:42 +0100 (CET)
Received: from kk-son ( []) by (8.11.7p3+Sun/8.11.7) with ESMTP id mAA0lOG00607; Mon, 10 Nov 2008 01:47:24 +0100 (CET)
Date: Mon, 10 Nov 2008 01:47:28 +0100
From: Andrew Yourtchenko <>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Cc:,, David Borman <>, Fernando Gont <>
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"

On Sat, 8 Nov 2008, Joe Touch wrote:

> I expect that, even if the IETF had a compliance process, the specs are
> always out of sync with what is deployed, and represent what
> implementations should try to achieve.

I think you did not mention one step before that - that the creation of 
the specs in the first place is to ensure the interoperability, not just 
for the sake of the specs themselves.

If the interoperability is already achieved by other means ("the running 
code" deployed everywhere), the specs become irrelevant. If then complying 
to the specs breaks that interoperability, they become outright harmful.

> Implementers should design protocols to specs; they should design
> applications to specs together with man pages and errata that discuss
> where the two diverge.

After reading the set of what I could find - the only conclusion 
regarding TCP Urgent that I could come to if I was designing an 
application - "Don't use it. At all."

On a related note, my understanding from reading the is that when 
the callers use SO_OOBINLINE in an attempt to be the "RFC-compliant", the 
urgent flag and pointer are pretty much a no-op altogether - maybe someone 
could correct me if I missed something:

"Note  When the SO_OOBINLINE socket option is set, the SIOCATMARK IOCTL 
always returns TRUE, and OOB data is returned to the user as normal 

> IMO, the specs cannot constantly be downgraded to represent what is
> implemented solely for that reason; downgrading can - and should - occur
> if we, as a community, decide to change what we *want* the protocol to do.

This is a good point - so I will take a risk of being burned in-place for 
heresy :) - and will put a few open questions of a broader scope to the 

1) Given the state of the matters and practical experience, are the OOB 
notifications (which TCP Urgent boils down to?) utilised enough in the 
today's (and tomorrow's) world to have them as part of the "core" protocol 
header as opposed to being an option ?

(searching suggests this has already been on the table back in '94 as one 
of the "small changes" within the tcpng bounds - but I was not able to 
find any discussions on the topic - I presume they happened offline - so 
would very much appreciate an enlightenment from someone who happened to 
be part of those discussions).

2) Would we want to more effectively utilise these 16 bits in the TCP 
header (assuming the URG flag rests at "0"), rather than transmitting two 
zero bytes for 99.99% of the cases ?

tcpm mailing list