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
- [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- [tcpm] ICMP error origination timeliness Pekka Savola
- Re: [tcpm] ICMP error origination timeliness Joe Touch
- Re: [tcpm] ICMP error origination timeliness Anantha Ramaiah (ananth)
- Re: [tcpm] ICMP error origination timeliness Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)