Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)

Andrew Newton <andy@hxr.us> Wed, 16 August 2006 18:04 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPl0-000680-PG; Wed, 16 Aug 2006 14:04:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPkz-00065R-GQ for ietf@ietf.org; Wed, 16 Aug 2006 14:04:45 -0400
Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDPkt-0007Gi-85 for ietf@ietf.org; Wed, 16 Aug 2006 14:04:45 -0400
Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 16 Aug 2006 14:04:31 -0400 id 01588015.44E35E30.00004CBA
Message-ID: <44E35E27.4060905@hxr.us>
Date: Wed, 16 Aug 2006 14:04:23 -0400
From: Andrew Newton <andy@hxr.us>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@netlab.nec.de>
References: <E1GCknR-0004hD-Jt@stiedprstage1.ietf.org> <44E1D050.F9A@xyzzy.claranet.de> <44E1EAEF.3030505@hxr.us> <44E2C737.8000402@alvestrand.no> <44E3400E.7050409@hxr.us> <9CD4B093-7A1D-4EE0-8B8E-9E2200A0E656@netlab.nec.de>
In-Reply-To: <9CD4B093-7A1D-4EE0-8B8E-9E2200A0E656@netlab.nec.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Harald Alvestrand <harald@alvestrand.no>, ietf@ietf.org
Subject: Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Lars Eggert wrote:
>> I just checked the simple user-drive, cli client I wrote and it 
>> doesn't retransmit at all (perhaps not the best UI experience).
> 
> the issue isn't with retransmissions. If - to use Harald's example - no 
> reply arrives for 70 out of 100 issued requests, this is a pretty strong 
> indication that the server or something on the way to or from the server 
> is congested. In response to such a signal, the request rate should be 
> reduced.

I'm not disagreeing.  I was merely pointing to one reason why this never 
came up as feed back from implementations.

> I'd also like to bring up a second, somewhat related issue. Section 3 says:
> 
>    Each IRIS-LWZ query or response is contained in a single UDP packet.
>    Servers MUST be prepared to accepted packets as large as 4000 octets,
>    and clients MUST NOT send packets larger than 4000 octets.
> 
> and Section 4 says
> 
>    2.  If a request is less than or equal to 4000 octets, send it
>        uncompressed.
> 
>    3.  If a request can be compressed to a size less than or equal to
>        4000 octets, send the request using compression.  Otherwise use
>        another transfer protocol.
> 
> Sending packets larger than the minimum MTU of ~512 bytes is likely to 
> cause fragmentation, which can significantly reduce transmission 
> efficiency and reliability [1] and cause data corruption [2].

This section came about as feedback from a server implementation where the 
implementor wanted to know how big of a buffer to reserve.  To answer your 
question below, 4000 was picked using DNSSEC as guidance.  However, looking 
at my code I see that MTU is the actual maximum value (I'll ask what others 
have done).  There likely should be a step 0: determine maximum size of 
packet (the lesser of mtu or 4000, which is almost always likely to be mtu).

> Fragmentation becomes more likely as packets get larger. With packets of 
> 4000 bytes (where does this number come from, anyway?), fragmentation is 
> pretty much guaranteed across most links. If IRIS-LZW messages are 
> expected to be larger than ~512 bytes in general, the use of a transport 
> protocol other than UDP is probably a good idea.

That section does say: "Not all IRIS requests and responses will be able to 
utilize UDP and may require the use of other transfer protocols (i.e. 
IRIS-XPC and/or BEEP)."

-andy


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf