Re: [EME] Re: transport recovery at the APP layer ?
Joe Touch <touch@ISI.EDU> Fri, 17 November 2006 18:29 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8SU-00032L-QK; Fri, 17 Nov 2006 13:29:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8ST-00032D-Rx for eme@irtf.org; Fri, 17 Nov 2006 13:29:01 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8S7-0007RP-Nx for eme@irtf.org; Fri, 17 Nov 2006 13:29:01 -0500
Received: from [127.0.0.1] (priras01.isi.edu [128.9.176.219]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAHISLkI019689; Fri, 17 Nov 2006 10:28:23 -0800 (PST)
Message-ID: <455DFF44.9060208@isi.edu>
Date: Fri, 17 Nov 2006 10:28:20 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Mark Baker <distobj@acm.org>
Subject: Re: [EME] Re: transport recovery at the APP layer ?
References: <E6F7A586E0A3F94D921755964F6BE00662575C@EXCHANGE2.cs.cornell.edu> <455B48BD.5050201@isi.edu> <455B56C9.7080307@rd-iptech.com> <455B6358.4000703@isi.edu> <455C38AC.1090306@rd-iptech.com> <455CDFFF.8000500@isi.edu> <455D9BD5.7000900@wanadoo.fr> <1163775763.8736.114.camel@sioux.systems.cs.cornell.edu> <c70bc85d0611170827t36b9443fm2b5581721142b769@mail.gmail.com> <455DE7D1.6030805@isi.edu> <c70bc85d0611170940s26d906aak4241fe728be5590d@mail.gmail.com>
In-Reply-To: <c70bc85d0611170940s26d906aak4241fe728be5590d@mail.gmail.com>
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: eme <eme@irtf.org>, Rémi Després <remi.despres@wanadoo.fr>
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1401291216=="
Errors-To: eme-bounces@irtf.org
Mark Baker wrote: > On 11/17/06, Joe Touch <touch@isi.edu> wrote: >> > While it's certainly true that applications are free to attribute >> > application layer semantics to transport layer signals (e.g. HTTP >> > 1.0), it is not the case that all applications do so (e.g. HTTP 1.1). >> >> If you're referring to persistent connections, that predated 1.1 as an >> add-on to 1.0 (though not in the base 1.0). > > I was referring to how HTTP 1.0 responses were framed, specifically > the last sentence of this paragraph from sec 7.2.2 of RFC 1945; > > When an Entity-Body is included with a message, the length of that > body may be determined in one of two ways. If a Content-Length header > field is present, its value in bytes represents the length of the > Entity-Body. Otherwise, the body length is determined by the closing > of the connection by the server. > > ... which is a layering problem that HTTP 1.1 fixed by mandating > persistent connections. See RFC2616, sec 8.1.1: HTTP implementations SHOULD implement persistent connections. When they don't, the old semantics persist. >> HTTP isn't the only application around, as you note. Unless this RG is >> focused on HTTP interactions with middleboxes, it needs to consider the >> impact on all applications. > > I'm glad to hear you say that, because IMO, doing so requires keeping > our layers layered and not assuming application semantics to TCP > signals. Doing that means keeping TCP semantics, which means that a FIN/ACK means what a FIN/ACK means - that the -endpoint- got the data, not that a middlebox somewhere else did. Joe
_______________________________________________ EME mailing list EME@irtf.org https://www1.ietf.org/mailman/listinfo/eme
- [EME] The virtual circuit trap mentioned in the E… Rémi Després
- Re: [Fwd: [EME] The virtual circuit trap mentione… Rémi Després
- RE: [EME] The virtual circuit trap mentioned in t… Paul Francis
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Joe Touch
- Re: [EME] The virtual circuit trap mentioned in t… Scott W Brim
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- RE: [EME] The virtual circuit trap mentioned in t… Paul Francis
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Joe Touch
- [EME] transport recovery at the APP layer ? Rémi Després
- [EME] Re: transport recovery at the APP layer ? Joe Touch
- RE: [EME] Re: transport recovery at the APP layer… Henry Sinnreich
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- [EME] Re: transport recovery at the APP layer ? Rémi Després
- RE: [EME] Re: transport recovery at the APP layer… Paul Francis
- Re: [EME] Re: transport recovery at the APP layer… Rémi Després
- RE: [EME] Re: transport recovery at the APP layer… Paul Francis
- [EME] Re: transport recovery at the APP layer ? Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Yangwoo Ko
- [EME] Re: transport recovery at the APP layer ? Rémi Després
- Re: [EME] Re: transport recovery at the APP layer… Saikat Guha
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Mark Baker
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Mark Baker
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Mark Baker
- Re: [EME] Re: transport recovery at the APP layer… Saikat Guha
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- [EME] Relationship betwen Rémi Després
- [EME] TCP close semantics Rémi Després
- [EME] Re: TCP close semantics Joe Touch
- [EME] Re: TCP close semantics Rémi Després
- Re: [EME] Relationship betwen Lars Eggert