Re: Where we stand and where we are going
Rob Austein <sra@hactrn.net> Fri, 28 June 2002 02:15 UTC
Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYE00N0A8X10O@eListX.com> (original mail from ietf-irnss-moderator@lists.elistx.com); Thu, 27 Jun 2002 22:15:01 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYE00J011DBY4@eListX.com> for ietf-irnss-moderator@lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 19:31:59 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYE00J011DAY3@eListX.com> for ietf-irnss-moderator@lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com) ; Thu, 27 Jun 2002 19:31:58 -0400 (EDT)
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYE00J041DAY0@eListX.com> for ietf-irnss-moderator@lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 19:31:58 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYE00J011DAXY@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 19:31:58 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYE00J011DAXX@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 19:31:58 -0400 (EDT)
Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYE00IA81D9UB@eListX.com> for ietf-irnss@lists.elistx.com; Thu, 27 Jun 2002 19:31:57 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id BCAB018AC for <ietf-irnss@lists.elistx.com>; Thu, 27 Jun 2002 19:31:43 -0400 (EDT)
Date: Thu, 27 Jun 2002 19:31:43 -0400
From: Rob Austein <sra@hactrn.net>
Subject: Re: Where we stand and where we are going
In-reply-to: <20020627091917.F24592@bailey.dscga.com>
To: ietf-irnss@lists.elistx.com
Message-id: <20020627233143.BCAB018AC@thrintun.hactrn.net>
MIME-version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-type: text/plain; charset="US-ASCII"
User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN)
References: <20020626094112.R24592@bailey.dscga.com> <200206261436.g5QEafBZ008897@nic-naa.net> <20020626204215.E10BB1D14@thrintun.hactrn.net> <20020627091917.F24592@bailey.dscga.com>
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss/>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>
At Thu, 27 Jun 2002 09:19:17 -0400, Michael Mealling wrote: > > On Wed, Jun 26, 2002 at 04:42:15PM -0400, Rob Austein wrote: > > Ok, I've been doing a lot of thinking in this realm and talking to all > sorts of people and I keep hearing different things. Here's the FUD I > keep hearing: > > 1) IP fragmentation on the Internet is awful so if you do UDP packets > larger than 1500 bytes you will probably loose one of the fragments > about 10 percent of the time Which, for many protocols, would be a Bad Thing (tm), but for an idempotent protocol in which it is cheaper to re-run the query than to stash replies in case something bad happens, this might be the best one can do. > 2) Attempts to do UDP fragementation at the application layer and not the > IP layer just means you're going to reinvent all of TCP over again so > why bother trying and just use TCP. Yeah, I've had that conversation too. A few years ago I suggested reimplementing portions of NETBLT over UDP, and was roundly trounced for failing to understand the behavior of a tail-drop universe. I have not yet figured out whether I really believe that argument, but I think it would be safe to say that we understand single-datagram UDP, we understand TCP, and we may understand a few other protocols, but the more general issues of timing, retransmission (ie, timing), and buffering (ie, timing) for transport protocols are significantly more "interesting" than one might wish (in the sense of the Chinese curse). > 3) "Try with UDP and if it fails retry with TCP" is "good enough". <insert > all of your "good enough is the enemy of good" verbage here> If you're willing to live with approximately an order of magnitude increase in load as the cost of failover, this might indeed be the least bad option. Transaction TCP shaves a bit off of that, but in practice one gets to a point of diminishing returns very quickly in the transport protocol space, if only because transport protocols usually live in OS kernels. > I have had two instances where the usage profile of a protocol suggests > that 99% of the responses will be less than 2K and the interaction is > stateless and connection-less. Inheriting the full session semantics of TCP > isn't required. But neither is the sad state of UDP packet size limitations. > > My proposed solution is to limit UDP packet sizes to 512 bytes and put > packet sequence numbers on them. You still have a connectionless interaction > but it a) puts the packet size into a realm with a higher probability of > success and b) allows for a handful of those packets to get through. I'm > not sure if you need more than that. You can still do the "well if > that didn't work I can always do TCP"... I did a think piece years ago on transport requirements for DNS, as input to a BOF that Vern held in, um, Orlando. No doubt I've still got it somewhere. The 5 cent version is that transport requirements for a lightweight idempotent query protocol with many orders of magnitude more clients than servers are, um, kind of whacky. So we have stayed with UDP for DNS, but have added the aforementioned EDNS0 size "negotiation"[*] extension. [*] It's not a negotation, just a statement by the client that the server should please feel free to generate a response up to N bytes long. Life is wierd when a conversation only lasts for two packets.
- Re: Where we stand and where we are going Eric Brunner-Williams in Portland Maine
- Re: Where we stand and where we are going Rob Austein
- Re: Where we stand and where we are going Eric Brunner-Williams in Portland Maine
- RE: Where we stand and where we are going John C Klensin
- RE: Where we stand and where we are going Nicolas Popp
- Re: Where we stand and where we are going Patrik Fältström
- Re: Where we stand and where we are going Michael Mealling
- Re: Where we stand and where we are going Eric Brunner-Williams in Portland Maine
- Re: Where we stand and where we are going Rob Austein
- Re: Where we stand and where we are going Eric Brunner-Williams in Portland Maine
- Re: Where we stand and where we are going Leslie Daigle
- Re: Where we stand and where we are going John C Klensin
- Re: Where we stand and where we are going Eric Brunner-Williams in Portland Maine
- Re: Where we stand and where we are going Michael Mealling
- Where we stand and where we are going John C Klensin
- Re: Where we stand and where we are going Erik Nordmark
- Re: Where we stand and where we are going bmanning