Re: [EME] The virtual circuit trap mentioned in the EME charter - need for clarification

Joe Touch <touch@ISI.EDU> Wed, 15 November 2006 16:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNej-0008RD-P4; Wed, 15 Nov 2006 11:30:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNej-0008R8-Fa for eme@irtf.org; Wed, 15 Nov 2006 11:30:33 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNeh-00052F-3s for eme@irtf.org; Wed, 15 Nov 2006 11:30:33 -0500
Received: from [127.0.0.1] (67.sub-75-209-245.myvzw.com [75.209.245.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAFGUGWx008143; Wed, 15 Nov 2006 08:30:19 -0800 (PST)
Message-ID: <455B4094.1080400@isi.edu>
Date: Wed, 15 Nov 2006 08:30:12 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Rémi Després <remi.despres@rd-iptech.com>
Subject: Re: [EME] The virtual circuit trap mentioned in the EME charter - need for clarification
References: <E6F7A586E0A3F94D921755964F6BE00662575C@EXCHANGE2.cs.cornell.edu> <4559FC5C.1090803@rd-iptech.com> <455A14AA.6010007@isi.edu> <455B3DDC.2060903@rd-iptech.com>
In-Reply-To: <455B3DDC.2060903@rd-iptech.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: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: eme@irtf.org
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="===============0665461581=="
Errors-To: eme-bounces@irtf.org


Rémi Després wrote:
> Thanks for the clear case description.
>  
> IMHO it should be considered more a problem of "NATs that may be passed
> around with rerouting" than as a problem of "NATs" as such.
>  (Most private NATs, that are the majority, cannot be passed around. No
> one would say that rerouting creates problems just because it can create
> problems when combined with NATs.)

Right. It's the NAT that creates the problem, because it's not tolerant
of the rerouting. Hard state in the middle of the network is dangerous
when paths are not pinned. (e.g., pinning can happen with explicit
signalling, or happens with proxies because of the termination of the
transport connection).

> Also, automatic reestablishment of a broken TCP connection is AFAIK
> systematic in common applications (mail, web, FTP etc.).
>  It can thus be deemed that this failure case not only is "recoverable"
> but is even "recovered" in the practical world.
>  (The recovery is even fast in general if the NAT which takes over,
> receiving a non-SYN TCP packet on an unknown connection, does return the
> RST which, if not lost, immediately clears the connection.)

It'd be useful to decide whether recovery includes the assumption that
the app layer will reconnect and restore E2E context. If that's
_assumed_ here, it'd be a first IMO.

Joe


> Joe Touch a écrit :
>> Rémi Després wrote:
>>   
>>> 2. I am not aware, personally, of failures of classical NATs that cannot
>>> be recovered (I mean those NATs that all of us use extensively)..
>>>     
>>
>> When there are multiple NATs that could be used for egress or ingress.
>>
>> An outgoing SYN establishes state at one NAT that is typically not
>> shared with the other NATs; if the routing changes behind the NAT to the
>> egress, or in front of the NAT on the return path, the connection
>> breaks. FWIW, that routing can change for many reasons, including
>> failure of a NAT box itself.
>>
>> Whether that's recoverable depends on whether you're willing to
>> reestablish a connection as part of recovery.
>>
>> Joe
>>
>>   

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

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