Re: [RAM] Tunnelling Route Reduction Protocol
jnc@mercury.lcs.mit.edu (Noel Chiappa) Wed, 22 August 2007 14:54 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 1INraq-0005nB-5K; Wed, 22 Aug 2007 10:54:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrap-0005n6-4R for ram@iab.org; Wed, 22 Aug 2007 10:53:59 -0400
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INrao-0005MI-Re for ram@iab.org; Wed, 22 Aug 2007 10:53:59 -0400
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 90D7887303; Wed, 22 Aug 2007 10:53:50 -0400 (EDT)
To: ram@iab.org
Subject: Re: [RAM] Tunnelling Route Reduction Protocol
Message-Id: <20070822145350.90D7887303@mercury.lcs.mit.edu>
Date: Wed, 22 Aug 2007 10:53:50 -0400
From: jnc@mercury.lcs.mit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: jnc@mercury.lcs.mit.edu
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
> From: Brian E Carpenter <brian.e.carpenter@gmail.com> >> 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. 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. True, but there's an obvious path to take in looking for delay improvments, which is to 'piggyback' the reverse mapping information on the connection opening. (Appending control traffic to user data is a technique with a long history in the data comm field, one that dates back to the ARPANet, where requests for the allocation of packet reassembly buffers in destination IMPs were piggybacked on the initial data fragment...) > There are perhaps some interesting DDOS attacks there. Alas, even with piggybacking on data traffic, there are a host of security issues. Sigh, TANSTAAFL... Noel _______________________________________________ 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