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
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Frank Ellermann
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Andrew Newton
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Marcos Sanz/Denic
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Ted Hardie
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Sam Hartman
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Frank Ellermann
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Frank Ellermann
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Andrew Newton
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Andrew Newton
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Sam Hartman
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… kent crispin
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Lars Eggert
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Andrew Newton
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Harald Alvestrand
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… william(at)elan.net
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Todd Glassey
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Ted Faber
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Ted Faber
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Randy Presuhn
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Andrew Newton
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Ned Freed
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Harald Alvestrand
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Mark Townsley
- Re: Last Call: 'A Lightweight UDP Transfer Protoc… Sam Hartman