Re: [EME] Re: transport recovery at the APP layer ?
"Mark Baker" <distobj@acm.org> Fri, 17 November 2006 19:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9eB-00007O-6f; Fri, 17 Nov 2006 14:45:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9e9-00007B-8Z for eme@irtf.org; Fri, 17 Nov 2006 14:45:09 -0500
Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl9e0-0000v3-Fe for eme@irtf.org; Fri, 17 Nov 2006 14:45:09 -0500
Received: by ug-out-1314.google.com with SMTP id o4so947758uge for <eme@irtf.org>; Fri, 17 Nov 2006 11:44:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g9Sjc2fkZLZIR9czBqaDdoDFpR0bbnYMIwFV7Igg/p4W2oDjbvPp4ARSukjyg3B7S5S1+rOjs+FYXvMywzMNqa26LwDRpyEYxJMrwE5HMs3rC3jvKZfeNtoTIO3jIk7Yq3C++cURCiIPjoDG1LvWv2dIO7Dua2oiU0xoTYJQ9sc=
Received: by 10.78.204.7 with SMTP id b7mr2298300hug.1163792699299; Fri, 17 Nov 2006 11:44:59 -0800 (PST)
Received: by 10.78.174.12 with HTTP; Fri, 17 Nov 2006 11:44:59 -0800 (PST)
Message-ID: <c70bc85d0611171144t2b6bb817w12c5df61c28adeb7@mail.gmail.com>
Date: Fri, 17 Nov 2006 14:44:59 -0500
From: Mark Baker <distobj@acm.org>
To: Joe Touch <touch@isi.edu>
Subject: Re: [EME] Re: transport recovery at the APP layer ?
In-Reply-To: <455DFF44.9060208@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E6F7A586E0A3F94D921755964F6BE00662575C@EXCHANGE2.cs.cornell.edu> <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> <455DFF44.9060208@isi.edu>
X-Google-Sender-Auth: 1836c9080ba44558
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
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>
Errors-To: eme-bounces@irtf.org
On 11/17/06, Joe Touch <touch@isi.edu> wrote: > > ... 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. Right, my bad. I meant making them the default. > When they don't, the old semantics persist. Old semantics persist because of compatibility rules, but I still consider the layering problem "fixed". Anyhow, my point is that assuming ACKed FINs meant something to the application would break some applications that don't already make that assumption. > >> 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. Right. Middleboxes should behave like they're in the middle, IMO 8-) Mark. _______________________________________________ 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