Re: Where we stand and where we are going

Patrik Fältström <paf@cisco.com> Thu, 27 June 2002 17:26 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00804KFD7C@eListX.com> (original mail from paf@cisco.com); Thu, 27 Jun 2002 13:26:01 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00801KFD7A@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 13:26:01 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00801KFC79@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 13:26:00 -0400 (EDT)
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYD0037OKFCBW@eListX.com> for ietf-irnss@lists.elistx.com; Thu, 27 Jun 2002 13:26:00 -0400 (EDT)
Received: from xbe-lon-303.cisco.com (xbe-lon-303.cisco.com [64.103.98.22]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5RHOvVq025776; Thu, 27 Jun 2002 19:24:59 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 27 Jun 2002 18:25:25 +0100
Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 27 Jun 2002 19:25:24 +0200
Date: Thu, 27 Jun 2002 19:20:31 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: Where we stand and where we are going
In-reply-to: <20020627091917.F24592@bailey.dscga.com>
To: Michael Mealling <michael@neonym.net>, Rob Austein <sra+irnss@hactrn.net>
Cc: ietf-irnss@lists.elistx.com
Message-id: <12033806.1025205631@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.2.0 (Mac OS X)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
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>
X-OriginalArrivalTime: 27 Jun 2002 17:25:24.0476 (UTC) FILETIME=[9F35BBC0:01C21DFF]

--On 2002-06-27 09.19 -0400 Michael Mealling <michael@neonym.net> wrote:

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

As soon as you will send more than one packet, you need congestion control
and other things from TCP.

I rather say one can send data in either "one packet" or "many". Many
packets should be over TCP (or something else with congestion control)
while one packet can be over UDP.

That said, any protocol today needs to have negotiation/announcement of
capabilities from both a client and server perspective.

So, client send one packet to server. If server detect the packet was
fragmented, and some data which was wanted was missing, it can send back
"try again over better transport".

My question is: Can not a packet include in the beginning a length
indication in the beginning of the packet so the server can detect if MTU
was too small?

   paf