Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)
"william(at)elan.net" <william@elan.net> Wed, 16 August 2006 21:21 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSp7-000447-6s; Wed, 16 Aug 2006 17:21:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSp5-000433-RB for ietf@ietf.org; Wed, 16 Aug 2006 17:21:11 -0400
Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDSp4-0007Aj-CP for ietf@ietf.org; Wed, 16 Aug 2006 17:21:11 -0400
Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k7GLKqef032066; Wed, 16 Aug 2006 14:20:52 -0700
Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k7GLKq22032063; Wed, 16 Aug 2006 14:20:52 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Wed, 16 Aug 2006 14:20:51 -0700
From: "william(at)elan.net" <william@elan.net>
To: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <44E2C737.8000402@alvestrand.no>
Message-ID: <Pine.LNX.4.62.0608161414110.26667@sokol.elan.net>
References: <E1GCknR-0004hD-Jt@stiedprstage1.ietf.org> <44E1D050.F9A@xyzzy.claranet.de> <44E1EAEF.3030505@hxr.us> <44E2C737.8000402@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: 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
On Wed, 16 Aug 2006, Harald Alvestrand wrote: > Andrew Newton wrote: >>> 3 - Why is LWZ limited to UDP, desperately trying to solve >>> various size issues with delated XML and other tricks ? >> >> TCP is handled by XPC and BEEP. But for very short and quick answers (and >> lots of them, such as domain availability checks) UDP is better. Don't >> know what you mean by tricks, but the deflation is optional. > my congestion control alarm went off. > > after reviewing the document, it's still ringing. > > There's nothing in the document that says "if you want to send 4000 requests, > and 70 out of the first 100 get lost, you should slow down your sending rate > to that server". > > The word "retransmit" does not occur in the document. > The word "packet loss" does not occur in the document. > The word "congestion" does not occur in the document. Session control is why we have TCP. Tell us where 'retransmit', 'packet loss' and 'congestion' appear in DNS, DHCP or some other UDP-based protocol documents and I'm sure author of this spec will be happy to put something similar in his document. > 4000-byte UDP packets will have 3x the drop rate of 1500-byte UDP packets. This is general UDP issue specifically due to currently deployed network equipment. It need not be mentioned in every UDP-based protocol spec especially since its operations issue. > So retransmissions are more likely than with DNS over the same wire. > I can't envision an implementation of this that wouldn't retransmit. > So guidance is needed. > > Using UDP is fine, but I regard this specification as incomplete. > > Harald _______________________________________________ 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