Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt

Andrew Yourtchenko <ayourtch@cisco.com> Wed, 10 February 2010 23:36 UTC

Return-Path: <ayourtch@cisco.com>
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 03C0B3A7572 for <tcpm@core3.amsl.com>; Wed, 10 Feb 2010 15:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FHJ8aIQ9lV8t for <tcpm@core3.amsl.com>; Wed, 10 Feb 2010 15:36:56 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 958BE3A748E for <tcpm@ietf.org>; Wed, 10 Feb 2010 15:36:56 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o1ANc3xI022308; Thu, 11 Feb 2010 00:38:03 +0100 (CET)
Received: from ams-ayourtch-8716.cisco.com (ams-ayourtch-8716.cisco.com [10.55.144.247]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o1ANbvec009837; Thu, 11 Feb 2010 00:37:58 +0100 (CET)
Date: Thu, 11 Feb 2010 00:37:56 +0100
From: Andrew Yourtchenko <ayourtch@cisco.com>
X-X-Sender: ayourtch@ayourtch-lnx.stdio.be
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com>
Message-ID: <alpine.DEB.2.00.1002110025230.5125@ayourtch-lnx.stdio.be>
References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <C304DB494AC0C04C87C6A6E2FF5603DB47DD6035B8@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Cc: tcpm@ietf.org, David Borman <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt
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: <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: Wed, 10 Feb 2010 23:36:58 -0000

Hi Anantha,

On Wed, 10 Feb 2010, Anantha Ramaiah (ananth) wrote:

>
> I had reviewed this document in the earlier versions, just a read again
> caught this and I am seeking clarification :
>
> =============
> 5.  Advice to new applications employing TCP
>
>   As a result of the issues discussed in Section 3.4, new applications
>   SHOULD NOT employ the TCP urgent mechanism.  However, TCP
>   implementations MUST still include support for the urgent mechanism
>   such that existing applications can still use it.
> ================
>
> Why should we be even making this assertion : "new applications SHOULD
> NOT" employ urgent mechanism due to what is said in sec 3.4. The
> end-to-end semantics may get broken/altered due to many reasons and not
> just due to the middlebox fiddling with the URG flag/ptr. I guess my
> point is that why this document take pains in recommending something as
> a result of a middlebox behaviour. The best I have seen so far in
> documents with similar situation is to just mention that middlebox
> behaviour and leave it, do not make any recos based on the middlebox
> behaviour.

We should correct the "3.4" to "3" - i.e. not just middleboxes, but any 
stack that receives the TCP segment with URG flag, will not reliably know 
how exactly to treat it out of three possible interpretations - so any 
application that utilises this mechanism will be inherently very fragile. 
(An example is ABOR with FTP, which does not work correctly most of the 
time).

thanks,
andrew

>
> Makes sense?
>
> -Anantha
>
> PS:- I think this document is ready for LC and the above comment should
> not be construed in any way as to obstructing the document to its
> advancement to LC status.
>
>
>
>
>
>> -----Original Message-----
>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
>> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>> Sent: Wednesday, February 10, 2010 10:43 AM
>> To: David Borman; Fernando Gont; Andrew Yourtchenko (ayourtch)
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt
>>
>> I concur with Michael's suggested edits, plus here are some
>> more comments.  Overall, I think it's in good shape and just
>> about ready to publish.  A minor update should be all that's
>> needed, but I do want to make sure that one of the
>> recommendations is worded correctly (see final comment below).
>>
>> Editorial:
>>
>> - section 1, paragraph 3:
>>   "IT accommodates" -> "it accommodates" ?
>>
>> - section 1, paragraph 3:
>>   "using urgent the urgent" -> "using the urgent"
>>
>> - section 1, paragraph 4:
>>   "how current TCP implementations" ->
>>   "how some current TCP implementations"
>>
>>
>> - section 3.2, paragraph 1:
>>   "never reflected into" -> "never was reflected in"
>>
>>
>> Semi-Technical:
>>
>> - section 2.3 - on the allowed length of urgent data, should this
>>   mention that obviously there is a limitation due to the length
>>   of a sequence number field?  You can't send a terabyte of urgent
>>   data.
>>
>> - section 6:
>>   I think it's not worded correctly when we say that applications
>>   using the sockets API MUST set SO_OOBINLINE.  What we really
>>   want to say is more like:
>>
>>   "Even though applications SHOULD NOT employ the urgent mechanism,
>>    applications that require the use of urgent data MUST set
>>    SO_OOBINLINE."
>>
>>   Right?  Apps that don't use urgent data shouldn't have to be
>>   bothered by the fact that it's broken.
>>
>> --
>> Wes Eddy
>> MTI Systems
>>
>>
>>> -----Original Message-----
>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]
>> On Behalf Of
>>> David Borman
>>> Sent: Friday, February 05, 2010 2:38 PM
>>> To: tcpm@ietf.org WG
>>> Cc: tcpm-chairs@tools.ietf.org; ayourtch@cisco.com; Fernando Gont
>>> Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt
>>>
>>> Note: As recent discussions on this list have indicated, we need
>>> members of this mailing list to be involved.  Please take
>> the time to
>>> read through this document and send a message to the mailing list
>>> either supporting publishing this document, or commenting on
>> why it is
>>> not ready to be published.  This particular document is
>> quite short and
>>> easy to understand.  -David Borman, TCPM co-chair.
>>> ----------------------------
>>>
>>> This is to announce the start of the WG Last Call for:
>>>
>>> Title           : On the implementation of the TCP urgent mechanism
>>> Author(s)       : F. Gont and A. Yourtchenko
>>> Filename        : draft-ietf-tcpm-urgent-data-02.txt
>>> Pages           : 13
>>> Date            : November 26, 2009
>>> Intended Status : Proposed Standard
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-da
>> ta-02.txt
>>>
>>> It is our understanding that all the feedback has been incorporated
>>> into this latest version and that there are no known
>> outstanding issues
>>> with this document.
>>>
>>> Please send feedback to the list.
>>>
>>> The WGLC will end on Friday, February 19, 2010.
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>