[rddp] Re: [Tsvwg] "DO IT RIGHT", or "DON'T DO IT AT ALL"
Joe Touch <touch@ISI.EDU> Fri, 06 December 2002 03:55 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12563 for <rddp-archive@odin.ietf.org>; Thu, 5 Dec 2002 22:55:13 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB63vhD15118 for rddp-archive@odin.ietf.org; Thu, 5 Dec 2002 22:57:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB63vgv15112 for <rddp-web-archive@optimus.ietf.org>; Thu, 5 Dec 2002 22:57:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12527 for <rddp-web-archive@ietf.org>; Thu, 5 Dec 2002 22:54:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB63v5v15032; Thu, 5 Dec 2002 22:57:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Mcmv29171 for <rddp@optimus.ietf.org>; Thu, 5 Dec 2002 17:38:48 -0500
Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03271; Thu, 5 Dec 2002 17:35:50 -0500 (EST)
Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gB5MceC07605; Thu, 5 Dec 2002 14:38:40 -0800 (PST)
Message-ID: <3DEFD56B.5060501@isi.edu>
Date: Thu, 05 Dec 2002 14:38:35 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Williams, Jim" <Jim.Williams@emulex.com>
CC: "'tsvwg@ietf.org'" <tsvwg@ietf.org>, "'rddp@ietf.org'" <rddp@ietf.org>
References: <3356669BBE90C448AD4645C843E2BF289B8F59@xbl.ma.emulex.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [rddp] Re: [Tsvwg] "DO IT RIGHT", or "DON'T DO IT AT ALL"
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Williams, Jim wrote: > The subject under discussion here is transforming > TCP into a record aligned transport to allow receivers > to do some level of ULP processing prior reassembly > of the TCP stream. The specific goal is to enable > an RDDP protocol to directly place incoming > data even if TCP segments arrive out of order. > > At least two drafts have been submitted which > propose mechanisms: > > draft-ietf-tsvwg-tcp-ulp-frame-01.txt [tuf] (expired) > and > draft-culley-iwarp-mpa-00.txt [mpa] > > In Atlanta I argued the case for "DON'T DO IT AT ALL". > The case being that TCP is a stream protocol and should > not be used otherwise. SCTP is a record protocol and > should be used when a record protocol is needed. > And that "fixing" TCP rather than switching to SCTP > is the wrong architectural direction. > > However in that aftermath of Atlanta I fear that > my argument is losing within the RDDP group, so I would > like to at least explore the alternative. I'd say "DON'T BOTHER AT ALL". Here's why: 1- anything that really does something useful is going to require EITHER a change to TCP semantics (the SEND/RECEIVE etc. API) OR to default to current semantics 2- changing semantics of the default case is simply not an option. There's too many critical (e.g., financial, commerce, etc.) systems that are based on existing semantics. We don't know what will break or when, and setting up a wide-scale gamble simply isn't appropriate. 3- changing semantics of a non-default case begs the question: why not just compile in a different protocol? SCTP, DCP, or write your own on UDP. The answer I've been hearing is "we need it now, and need it to work for legacy apps". But that means you also need legacy semantics, which means #2 applies. Finally, I'd appreciate hearing a discussion of why this should all work that doesn't include some glaring errors. E.g., at the last meeting we all heard about how TCP with Nagle off (NODELAY) sends packets that match what the send calls issue. That simply isn't the case, never was, and cannot be assumed regardless. E.g., how do you know the path MTU didn't change between when you checked it/issued the write and when the packet is emitted? Many of the other debates about these other protocols ignore the fact that the TCP spec is defined in terms of two interfaces - one below (the packets) and one above (the API, in terms of generic SEND/RECV/OPEN/CLOSE etc.) The API appears to be ignored in most cases. ... > Both [tuf] and [mpa] state > that the receiver might or might not get record aligned > segments, and they both add another layer of protocol > processing to allow the receiver to determine whether > the alignment attempt was or was not successful. They > both require that the receiver to support the dual > complexity of handling both aligned and unaligned > segments on a given connection. > > To me, this seems to have the type of undesirable > complexity often associated with ill advised, ad hoc > solutions. I would encourage that some thought > be given to a more cleanly architected solutions > even if the down side is greater impact on TCP > bahavior. How about realizing that: these are TWO different transport protocols, and deserve two different protocol numbers? > There are two fundamental problems with guaranteeing > record alignment to the receiver. > > 1. How can the sender always align. > > 2. How can middle-boxes be prevented from > re-segmenting the TCP stream. > > With respect to 1., both drafts state that alignment > will usually be done, but list a number of exception > cases under which the sender will not attempt to > align. > > I would propose as part of "doing it right" that > a sender which agrees to align must ALWAYS align > records with TCP segments. I will not attempt > now to list here all the implication of this, but > the summary is that this will require > small but substantive changes to TCP > sender behavior, and that these changes, if done > right, will not break interoperability with > existing implementations. (However this is > a tricky area, and until the work is done, > it is not possible to be sure.) > > With respect to 2., I would propose that senders > that agree to align should announce this intention > by adding a newly defined RECORD_ALIGNED TCP option > to the SYN segments used to set up the connection. Good luck on that. Middleboxes exist because the middlebox owners want them to, and often don't want to be seen. They already violate the E2E argument, and many aspects of the core specifications of the Internet (1122,1123, etc.). Now you expect them to respect a flag you put in the header. Why do you expect them to respect a new spec, when the don't respect the existing ones? ... > However, in practice this will not be a big enough > problem that it should drive protocol design in a > major way. Middle boxes that re-segment, and also > send a TCP option agreeing not to re-segment > are engaging in aberrant and erroneous behavior, > and will cause connections to quickly close in error. Yeah, right. Or the will cause the applications to break, and not work at all, as NATs often do. Then what? > The result is either they will be fixed, or > the affected receivers will be configured to > not assume alignment (ignore incoming RECORD_ALIGNED > options). How? When you're at a meeting and need to get to your email, then what? Did the NAT boxes that hit you last time magically disappear, or did your end or your servers' get reconfigured to work? This is not a useful path to spend further energy, IMO. Joe _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp
- [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL" Williams, Jim
- Re: [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL" David Robinson
- Re: [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL" Caitlin Bestler
- RE: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Uri Elzur
- [rddp] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL" Caitlin Bestler
- Re: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Caitlin Bestler
- [rddp] Re: [Tsvwg] "DO IT RIGHT", or "DON'T DO IT… Brian F. G. Bidulock
- Re: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Joe Touch
- Re: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] "DO IT RIGHT", or "DON'T DO IT… Joe Touch
- [rddp] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL" Joe Touch
- Re: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] "DO IT RIGHT", or "DON'T DO IT… Randall Stewart
- RE: [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL" Williams, Jim
- RE: [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL" Caitlin Bestler
- [rddp] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL" Caitlin Bestler
- Re: [rddp] Re: "DO IT RIGHT", or "DON'T DO IT AT … Caitlin Bestler
- Re: [Tsvwg] Re: [rddp] Re: "DO IT RIGHT", or "DON… Caitlin Bestler
- [rddp] RE: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Spencer Dawkins
- [rddp] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL" Joe Touch
- Re: [Tsvwg] Re: [rddp] Re: "DO IT RIGHT", or "DON… Brian F. G. Bidulock
- Re: [Tsvwg] RE: [rddp] "DO IT RIGHT", or "DON'T D… Qiaobing Xie
- Re: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Joe Touch
- RE: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T D… Spencer Dawkins
- Re: [Tsvwg] Re: [rddp] Re: "DO IT RIGHT", or "DON… Brian F. G. Bidulock
- [rddp] RE: "DO IT RIGHT", or "DON'T DO IT AT ALL" Williams, Jim
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Mark Allman
- [rddp] RE: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… pat_thaler
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Lars Eggert
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] RE: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Caitlin Bestler
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Caitlin Bestler
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Caitlin Bestler
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Sam Liang
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Mark Allman
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Sam Liang
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- RE: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Teisberg, Robert
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Caitlin Bestler
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Qiaobing Xie
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… David Borman
- [rddp] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL" Williams, Jim
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Randall Stewart
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Qiaobing Xie
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Sam Liang
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Brian F. G. Bidulock
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Caitlin Bestler
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Randall Stewart
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Randall Stewart
- [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T D… Joe Touch
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Joe Touch
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Brian F. G. Bidulock
- Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON… Talpey, Thomas