Re: [tcpm] ICMP error origination timeliness

Joe Touch <touch@ISI.EDU> Mon, 07 April 2008 05:21 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F44B3A68F6; Sun, 6 Apr 2008 22:21:27 -0700 (PDT)
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 BFDE93A68F6 for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 22:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599]
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 5TqWfRl-y-b0 for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 22:21:25 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 064503A67AB for <tcpm@ietf.org>; Sun, 6 Apr 2008 22:21:25 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m375LJPr014944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Apr 2008 22:21:20 -0700 (PDT)
Message-ID: <47F9AF4F.4060208@isi.edu>
Date: Sun, 06 Apr 2008 22:21:19 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <alpine.LRH.1.10.0804070808290.20458@netcore.fi>
In-Reply-To: <alpine.LRH.1.10.0804070808290.20458@netcore.fi>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] ICMP error origination timeliness
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-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>
Content-Type: multipart/mixed; boundary="===============1109977816=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


Pekka Savola wrote:
> On Sun, 6 Apr 2008, Joe Touch wrote:
>> 	1) (my point) ICMPs are not required to be issued in a timely
>> 	fashion, or for every individual error, a legitimate situation
>> 	could involve receiving an old ICMP about an endpoint failure,
>> 	without receiving further updates on any particular schedule
>>
>> 	2) (Fernando's point) ICMPs are currently implemented widely
>> 	as not being issued in a timely fashion, with the same results
>> 	as #1
> 
> What is "timely fashion" in 2)?  What is not?  What are the scenarios 
> where this occurs?

Routers are not required to return ICMPs on any particular timescale.

Timely most specifically would mean "within the MSL during which the 
original TCP segment was intended to be limited to"; most practically, 
it might be "within one MSL of when the original TCP segment was 
received and triggered the corresponding ICMP".

Non-timely would definitely mean "more than one MSL after the TCP 
segment that triggered the ICMP event was received". That could occur 
when a router paces its ICMP output (as recommended in RFC 1812), and 
when an implementation uses a tail-drop queue for that logging.

> ICMP error generation has always seemed "timely" to me.  The only 
> exception, in a way, that I've noticed is if ICMP error origination 
> rate-limiter is active at the moment the offending packet is received.

Exactly.

> The reason I say "in a way" is that the text above makes me think the 
> point is that ICMP error generation is delayed (which rate-limiters 
> don't do) rather than skipped altogether. Is point 2) referring to 
> rate-limiting or something else?

The case I described is when rate limiting causes a delay. Another case 
would be when messages are queued up and only periodically handled, and 
that router's control plane is under significant load.

Joe

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm