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

Andrew Yourtchenko <ayourtch@cisco.com> Mon, 10 November 2008 00:47 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 63A7C3A69B3; Sun, 9 Nov 2008 16:47:54 -0800 (PST)
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 8DBE53A69B3 for <tcpm@core3.amsl.com>; Sun, 9 Nov 2008 16:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.605
X-Spam-Level:
X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599]
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 T9niClIz7UnC for <tcpm@core3.amsl.com>; Sun, 9 Nov 2008 16:47:52 -0800 (PST)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4CB093A6813 for <tcpm@ietf.org>; Sun, 9 Nov 2008 16:47:52 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAA0lgu00636; Mon, 10 Nov 2008 01:47:42 +0100 (CET)
Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (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 (CET)
From: Andrew Yourtchenko <ayourtch@cisco.com>
X-X-Sender: ayourtch@zippy.stdio.be
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4915D19A.4070404@isi.edu>
Message-ID: <Pine.LNX.4.64.0811092134370.16978@zippy.stdio.be>
References: <200810280000.m9S00h4E029878@venus.xmundo.net> <A56C813C-B46D-4A02-A905-DD6B7E163156@windriver.com> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu>
MIME-Version: 1.0
Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>
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
Reply-To: ayourtch@cisco.com
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"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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 
http://msdn.microsoft.com/en-us/library/ms740102(VS.85).aspx 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 
data."

>
> 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 
community:

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 ?

thanks,
andrew
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm