Re: [DNSOP] TCP/UDP performances

Sebastian Castro <sebastian@nzrs.net.nz> Tue, 24 November 2009 22:57 UTC

Return-Path: <sebastian@nzrs.net.nz>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A004C3A6825 for <dnsop@core3.amsl.com>; Tue, 24 Nov 2009 14:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level:
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 I97eraN+xL8O for <dnsop@core3.amsl.com>; Tue, 24 Nov 2009 14:57:09 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 661F73A680C for <dnsop@ietf.org>; Tue, 24 Nov 2009 14:57:09 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 60D0E2DB852 for <dnsop@ietf.org>; Wed, 25 Nov 2009 11:57:04 +1300 (NZDT)
X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1m9mHrBx-To for <dnsop@ietf.org>; Wed, 25 Nov 2009 11:56:59 +1300 (NZDT)
Received: from [192.168.22.189] (unknown [192.168.22.189]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 5230B2DB29A for <dnsop@ietf.org>; Wed, 25 Nov 2009 11:56:59 +1300 (NZDT)
Message-ID: <4B0C64BA.40604@nzrs.net.nz>
Date: Wed, 25 Nov 2009 11:56:58 +1300
From: Sebastian Castro <sebastian@nzrs.net.nz>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
CC: dnsop@ietf.org
References: <51eafbcb0911240543m38c27080xc9c54cc1c3f6036c@mail.gmail.com>
In-Reply-To: <51eafbcb0911240543m38c27080xc9c54cc1c3f6036c@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [DNSOP] TCP/UDP performances
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2009 22:57:10 -0000

Daniel Migault wrote:
> Hi,

Hi,


> We are looking for measurements on the following points :
>    - How TCP affects DNS servers performances compared to UDP?
>    - Proportion of clients that switch to TCP?

The proportion of clients switching to TCP depends on what are the
clients asking and their EDNS signaling. The protocol indicates if a
response comes with the TC bit on, the query should be retried using TCP.

To get a Truncated Response I've seen two scenarios:

1. The client doesn't support EDNS and the response won't fit on 512 bytes.
2. The client does support EDNS but announces a small buffer size
(usually 512 bytes), creating the same situation described above. A
general version would be a EDNS-capable client that announces a buffer
not big enough to hold the response.

>    - What kind of client are they? Are they those that do not implement
> EDNS0?

I mentioned two scenarios above, with or without EDNS. May be someone
else can think about additional conditions.

> 
> Feel free to provide any paper links you know.

I'd like to suggest you two documents to read. One is the Root Zone
Augmentation and Impact Analysis[1] from Duane Wessels and Geoff Sisson
and recent Duane's presentation at OARC[2] in Beijing.

[1]
http://www.icann.org/en/topics/ssr/root-zone-augementation-analysis-17sep09-en.pdf
[2] https://www.dns-oarc.net/files/workshop-200911/Duane_Wessels.pdf

Personally I've been working on a DNS benchmarking tool (like queryperf)
that retries queries when the response has the TC bit on. I can't share
any results because my testing hasn't been rigorous and the reduction in
performance is related to the fraction of queries you have to retry.
Also the benchmark can be affected if you re-use the TCP socket or if
it's created on each retry (and destroyed afterwards).


Cheers
Sebastian

> 
> Regards,
> 
> Daniel
> 
> -- 
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop