Re: [EME] Re: transport recovery at the APP layer ?

Joe Touch <touch@ISI.EDU> Fri, 17 November 2006 20:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlA6Y-0005ZY-LR; Fri, 17 Nov 2006 15:14:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlA6X-0005ZM-Gd for eme@irtf.org; Fri, 17 Nov 2006 15:14:29 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlA6W-0004pU-5o for eme@irtf.org; Fri, 17 Nov 2006 15:14:29 -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 kAHKE4FS015844; Fri, 17 Nov 2006 12:14:06 -0800 (PST)
Message-ID: <455E180B.4050907@isi.edu>
Date: Fri, 17 Nov 2006 12:14:03 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Saikat Guha <saikat@cs.cornell.edu>
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> <455DFF44.9060208@isi.edu> <1163793934.17915.52.camel@sioux.systems.cs.cornell.edu>
In-Reply-To: <1163793934.17915.52.camel@sioux.systems.cs.cornell.edu>
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: 0ddefe323dd869ab027dbfff7eff0465
Cc: eme <eme@irtf.org>, esprés <remi.despres@wanadoo.fr>, "Rémi D"
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="===============1170523896=="
Errors-To: eme-bounces@irtf.org


Saikat Guha wrote:
> On Fri, 2006-11-17 at 10:28 -0800, Joe Touch wrote:
>> 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.
> 
> TCP has a number of semantics desirable and undesirable (see RFC 3135).
> WGs active in IETF such as TCPM and BEHAVE are working to preserve the
> semantics TCP offers. "Fixing" TCP or telling middleboxes  how to
> "correctly" handle FIN packets should not be in scope of EME.
...
> Should the path forged include a TCP link or a NAT/firewall, the TCPM
> and BEHAVE WGs define the protocol, semantics, who sends what packet and
> what that means for that protocol etc. IMHO, that should be out of scope
> of EME.

EME is a RG. IMO, it should definitely explore this interaction and
advise the IETF, which would then help set boundaries for future
TCPM/BEHAVE/etc. WGs. Those issues should not be driven by WGs.

Joe

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme