Re: [tcpm] ICMP error origination timeliness

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 07 April 2008 06:26 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 C41DF3A6A10; Sun, 6 Apr 2008 23:26:34 -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 4B9F13A6A10 for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 23:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 peFKNEYgNcE6 for <tcpm@core3.amsl.com>; Sun, 6 Apr 2008 23:26:32 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4029E3A689C for <tcpm@ietf.org>; Sun, 6 Apr 2008 23:26:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,616,1199692800"; d="scan'208";a="20180204"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2008 23:26:45 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m376Qibt027086; Sun, 6 Apr 2008 23:26:44 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m376Qi15014234; Mon, 7 Apr 2008 06:26:44 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 23:26:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 06 Apr 2008 23:26:13 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5804FA1162@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <47F9AF4F.4060208@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] ICMP error origination timeliness
Thread-Index: AciYb0Nee1tLbYFQSw+xVwrpUqxvygAADh1g
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> <47F9AF4F.4060208@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Joe Touch <touch@ISI.EDU>, Pekka Savola <pekkas@netcore.fi>
X-OriginalArrivalTime: 07 Apr 2008 06:26:44.0687 (UTC) FILETIME=[599ABDF0:01C89878]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2992; t=1207549605; x=1208413605; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20ICMP=20error=20origination=20t imeliness |Sender:=20; bh=6HqyAaBiIBCsIMoUohmdz/gWAvJPE8F7f1THARelAHw=; b=U1vuPd+j2vU/hnP0GIgaVNSEdvb7U4odRGjSLdy4bRo4MEowmlKr8aq38m /H5AAOOZknro6pAzCE1eCaAPucqRu5hfRfl/mADRHneKHcis6HAlYpwVH9tF 8Tu331NCGy;
Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

 
<snip>

> > 
> > 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.

Routers are not going to delay the ICMP message generation
unnecessarily. In most cases the ICMP messages are going to be generated
in orderly and timely fashion.

> 
> 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.

- Rate-limiting/ICMP messages being dropped can happen anytime/anywhere,
but overly delaying ICMP isn't common. Anyways the end-points
responsibility is to be robust and not fooled by the presense or the
absense of the ICMP messages. PMTU blackhole detection and recovery is
there for a reason. Since you cannot rely on the ICMP message being
generated always, if one is generated then putting some additional
checks to validate it doesn't look far-fetched, IMO. Please see below.

> > 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.

Even if all the conditions which you describe above are true, in most
cases the packet is going to dropped before sending a ICMP message.
(Eg;- DF bit set but needs to be fragment etc.,) in which case the
sender SNDUNA is not going to advance since it is not going to get an
ACK from the peer. This means that sender is going to see the ICMP
message (assuming one is going to generated) as the first respone to the
TCP segment it had sent on that particular TCP connection (forget
bi-directional data for a moment). OR is the scenario which is causing a
worry is that when the ACK arrived and advanced the SNDUNA, but the ICMP
arrived pretty late whose sequence # did not match and hence we dropped
it ( due to the recommendation of the draft), if so what is the big
deal? 

In a nutshell, the benefits of adding robustness by dropping the
suspicious ICMP messages far outwiegh the corner cases (which I am still
not convinced that those are real) where we don't process an "outdated"
ICMP message.

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