Re: [tcpm] poll for adoption of long connectivity disruptions draft

Joe Touch <touch@ISI.EDU> Thu, 10 September 2009 21:33 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12B528C0CE for <tcpm@core3.amsl.com>; Thu, 10 Sep 2009 14:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5LO62Ptt8lK for <tcpm@core3.amsl.com>; Thu, 10 Sep 2009 14:33:05 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 573A33A68AF for <tcpm@ietf.org>; Thu, 10 Sep 2009 14:33:05 -0700 (PDT)
Received: from [75.214.234.117] (117.sub-75-214-234.myvzw.com [75.214.234.117]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8ALX7vA027436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Sep 2009 14:33:09 -0700 (PDT)
Message-ID: <4AA97092.3080105@isi.edu>
Date: Thu, 10 Sep 2009 14:33:06 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Alexander Zimmermann <Alexander.Zimmermann@nets.rwth-aachen.de>
References: <C304DB494AC0C04C87C6A6E2FF5603DB479B8A30CD@NDJSSCC01.ndc.nasa.gov> <EBDBFEBB-F697-49A4-A665-DC06F3916CB6@iki.fi> <4AA6DF6D.10606@isi.edu> <E1F126EA-CB8E-47A1-B014-D0526E44BEDD@nets.rwth-aachen.de>
In-Reply-To: <E1F126EA-CB8E-47A1-B014-D0526E44BEDD@nets.rwth-aachen.de>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: n8ALX7vA027436
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2009 21:33:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...
>> > - --
>> >
>> > FWIW, this draft continues the erroneous assumption that ICMPs are  
>> > sent
>> > in a timely fashion. Routers aren't required to do this, and so the
>> > sequence number inside an ICMP should never be used as critical
>> > information. It'd be useful (if not important) to explain the impact  
>> > of
>> > this on the algorithm in the draft.
> 
> 
> Ack that we should it explain more deeply. However I have to disagree  
> with you: we explicitly allow routers to delay ICMPs, and try to  
> benefit from those "delayed" ICMPs as long as those delayed ICMPs  
> belong to the current RTO-induced loss recovery phase. Moreover, there  
> are two important things to note:
> 
> 1.) We check for an exact match of SND.UNA (no window etc.) with the  
> sequence number included in the ICMP DU. What are the chances that a  
> delayed ICMP matches SND.UNA, but not belonging to that RTO period  
> arrives while this same TCP connection (ports and IPs match) is in  
> timeout-based loss recovery? I say you better play lottery  ;-) 

A router that goes down and queues pending outgoing ICMPs, then emits
them when up, could win the lottery by design.

The question is whether it matters for your algorithm. If the connection
didn't proceed anyway and this is still a useful signal, then say so.

If the connection could proceed on other paths, and as a result the
sequence numbers would need to wrap and be in-window to work, then the
probability of this happening depends on the width of the window - which
has been getting larger, and could make such a lottery more likely than
you're planning for. Again, does it matter?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkqpcJIACgkQE5f5cImnZrs9oACePJC7XzJbjKBIpQsOX4o4cjAI
knoAn06lbo0bzlPj+rS/bDjIccSEbbko
=ravf
-----END PGP SIGNATURE-----