Re: Where we stand and where we are going

Michael Mealling <michael@neonym.net> Thu, 27 June 2002 13:20 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00M0492I1Z@eListX.com> (original mail from michael@bailey.dscga.com) ; Thu, 27 Jun 2002 09:20:43 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00M0192I1X@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 09:20:42 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00M0192I1W@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 09:20:42 -0400 (EDT)
Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYD00G9892HSS@eListX.com> for ietf-irnss@lists.elistx.com; Thu, 27 Jun 2002 09:20:42 -0400 (EDT)
Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5RDJIuK003702; Thu, 27 Jun 2002 09:19:18 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5RDJIwe003701; Thu, 27 Jun 2002 09:19:18 -0400 (EDT)
Date: Thu, 27 Jun 2002 09:19:17 -0400
From: Michael Mealling <michael@neonym.net>
Subject: Re: Where we stand and where we are going
In-reply-to: <20020626204215.E10BB1D14@thrintun.hactrn.net>
To: Rob Austein <sra+irnss@hactrn.net>
Cc: ietf-irnss@lists.elistx.com
Reply-to: Michael Mealling <michael@neonym.net>
Message-id: <20020627091917.F24592@bailey.dscga.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-disposition: inline
User-Agent: Mutt/1.3.22.1i
References: <20020626094112.R24592@bailey.dscga.com> <200206261436.g5QEafBZ008897@nic-naa.net> <20020626204215.E10BB1D14@thrintun.hactrn.net>
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>

On Wed, Jun 26, 2002 at 04:42:15PM -0400, Rob Austein wrote:
> At Wed, 26 Jun 2002 10:36:41 -0400, Eric Brunner-Williams in Portland Maine wrote:
> > 
> > A move toward binary, UDP-friendly packet format is good.
> 
> Just please, if we go down this road, let's put the UDP packet length
> negotiation junk into the initial rev of the protocol and not wire
> arbitrary length limits (other than those imposed by IP and UDP
> themselves) into the protocol the way that RFC 1035 did to DNS.
> 
> Retrofitting this (EDNS0) has been an interesting learning experience,
> but it's one that I'd prefer not to have to repeat in this lifetime.

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

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.

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>

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 really would like to hear some definitive answers on this topic because
it keeps coming up and a solution would make a heck of a lot of sense.

-MM


-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
michael@neonym.net      |                              | http://www.neonym.net