Re: [RAM] Tunnelling Route Reduction Protocol
"William Herrin" <bill@herrin.us> Wed, 22 August 2007 22:41 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INytW-0007Rr-MJ; Wed, 22 Aug 2007 18:41:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INytW-0007Rc-5v for ram@iab.org; Wed, 22 Aug 2007 18:41:46 -0400
Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INytU-0005js-Vc for ram@iab.org; Wed, 22 Aug 2007 18:41:46 -0400
Received: by nz-out-0506.google.com with SMTP id i28so197722nzi for <ram@iab.org>; Wed, 22 Aug 2007 15:41:44 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sQ7c4xk87iOv/5WmQaCZc6cloMzGxDqMzZ3rKqs7bXi+i3Xo0YIAPMmoaTAOhAq62+UxSTGzaWSv9A5y3srLMXU5BT35YTVt0pbM0bwFBEjs3jP1C0a191dzkj9rMTylfOpgHRWFRxH822vBPM3r5CADj8OVlQqIG49mmPK0bfA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ksHbYTcKp9PITnB311rD5GAN5SqIdzR9CCd17Q1i5MnjFBo8QVrqlZTO5hiE8+g4y+DJwN03xupmM8sdaSKkK5zUkdqhL3fdkD2A86lUYIDcX0uJzkIlp8WRY33YEHyqI3L80XQbakAoga9eVT+qBhFyHwtwFVUCLusrGS/QEH8=
Received: by 10.142.232.20 with SMTP id e20mr147075wfh.1187822503431; Wed, 22 Aug 2007 15:41:43 -0700 (PDT)
Received: by 10.143.159.7 with HTTP; Wed, 22 Aug 2007 15:41:43 -0700 (PDT)
Message-ID: <3c3e3fca0708221541w72cce046kbece41107e1da688@mail.gmail.com>
Date: Wed, 22 Aug 2007 18:41:43 -0400
From: William Herrin <bill@herrin.us>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [RAM] Tunnelling Route Reduction Protocol
In-Reply-To: <46CBF4A6.3020100@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> <46CBF4A6.3020100@gmail.com>
X-Google-Sender-Auth: efa6aa0dc0f7d712
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
On 8/22/07, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > On 2007-08-21 15:30, William Herrin wrote: > > 1. 99.9% of the time, the originator of the packet has already had to > > do a DNS lookup or some other lookup to map a name to an IP address. > > Wouldn't that be 49.95%? Half of all first packets tend to be > responses such as SYN/ACK that involve no DNS lookup. Hi Brian, Its still 99.9%; the return packet is part of the initial transaction. But you're right, there are potentially two extra lookup delays on that first transaction in addition to the original name to IP lookup. If the network operator is sloppy then there could be more. If the DNS resolver doesn't refer queries through a resolver on globally routable space or the authoratative name to ip DNS server isn't on globally routable space then there could be a dozen lookups to get to the point where the two endpoints are talking and all pertinent routes are cached. That's avoided by good operations practice, so I'm not too worried about it. > For a server > handling thousands of requests per second, adding a lookup means > holding thousands of TCBs in a wait state for the duration of the > lookup. There are perhaps some interesting DDOS attacks there. Shouldn't be much different that you see with SYN floods and SYN cookies now. I suspect the worst DOS would involve sending packets to random addresses. The ITR lookups run afoul of the same problem that Cisco fast-switching did: overwhelming the cache. The ITR would have to take care not to discard routes for sessions that have seen a lot of packets in favor of pending lookups or routes that have only seen a few packets. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- Re: [RAM] Tunnelling Route Reduction Protocol Noel Chiappa
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Robin Whittle
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Robin Whittle
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Brian E Carpenter
- Re: [RAM] Tunnelling Route Reduction Protocol Noel Chiappa
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin