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 >
- [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Michael Welzl
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Anantha Ramaiah (ananth)
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Andrew Yourtchenko
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… John Heffner
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Alexander Zimmermann
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.t… David Harrington