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

Alexander Zimmermann <> Thu, 10 September 2009 11:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFD7A3A6A35 for <>; Thu, 10 Sep 2009 04:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.158
X-Spam-Status: No, score=-4.158 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zzBGjOSDmGkX for <>; Thu, 10 Sep 2009 04:26:39 -0700 (PDT)
Received: from (mail-i4.informatik.RWTH-Aachen.DE []) by (Postfix) with ESMTP id 799A33A699A for <>; Thu, 10 Sep 2009 04:26:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A019457DCE; Thu, 10 Sep 2009 13:27:13 +0200 (CEST)
Received: from ([2002:89e2:d06::89e2:d06]) by ([2002:89e2:d05::89e2:d05]) with mapi; Thu, 10 Sep 2009 13:27:13 +0200
From: Alexander Zimmermann <>
To: Joe Touch <touch@ISI.EDU>
Date: Thu, 10 Sep 2009 13:27:12 +0200
Thread-Topic: [tcpm] poll for adoption of long connectivity disruptions draft
Thread-Index: AcoyCaQyikDQFABXScmN3KOEsKcI8w==
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: de-DE
Content-Language: en-US
acceptlanguage: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2009 11:26:41 -0000

Hi Joe,

thanks for your remarks. As always, comments are inline...


Am 09.09.2009 um 00:49 schrieb Joe Touch:

> Hash: SHA1
> Pasi Sarolahti wrote:
> ...
>> * Section 4.2, algorithm: this is really a nit, but might want to
>> clarify in step (5) that if ICMP DU contains non-TCP header it  
>> should be
>> ignored, without affecting the algorithm (right?)
> It's not clear whether that is a feature or a bug.
> If you have TCP that's idle, and other packets from your host  
> traverse a
> path and generate ICMP DUs, your TCP could benefit from reacting. I
> didn't see anything in 1122 that would prevent that.

In my opinion the algorithm should only respond to ICMPs which can be  
demultiplexed to a specific connection (see e-mail reply to Pasi).  
Exploiting other ICMP DUs may be possible, as a future work, but I  
fear it may be dangerous and collide with policy routing etc. For  
instance I wouldn't be surprised if there are "creative" ISPs which  
route HTTP connections differently than SMTP connections.

> - --
> 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 ;-)

2,) Even if such an very unlikely event ever occurs the impact of such  
an ICMP DU is obviously very low.

Partly this is explained in Section 4.3 in the paragraph about  
sequence number wraps. But we probably separately address the
special timing issues of ICMPs.

> Hie
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkqm32wACgkQE5f5cImnZruZ6QCgmy/Op6oqLMTq8XFoNSMNki6p
> 3zwAnRxph15X2K6pRQV1voL2PqJ3qVwf
> =rPsC
> _______________________________________________
> tcpm mailing list