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