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
- 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