Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)
Ned Freed <ned.freed@mrochek.com> Thu, 17 August 2006 00:48 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDW3d-0004Ha-VC; Wed, 16 Aug 2006 20:48:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDW3b-0004HV-Nj for ietf@ietf.org; Wed, 16 Aug 2006 20:48:23 -0400
Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDW3a-0001HE-9o for ietf@ietf.org; Wed, 16 Aug 2006 20:48:23 -0400
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M62H51BWG000LG3B@mauve.mrochek.com> for ietf@ietf.org; Wed, 16 Aug 2006 17:48:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1155775699; h=Date: From:Subject:MIME-version:Content-type; b=oa68iwDj67jrUqFnMC5G+NRLQ TB1SBOECNBVs5QXnUL2gjsrhqLTvpf44mbf99who2fYpB67Q5j9SiTY/Jng7w==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M627SOML2O0008CX@mauve.mrochek.com>; Wed, 16 Aug 2006 17:48:17 -0700 (PDT)
To: williamatelannet <william@elan.net>
Message-id: <01M62H50L24E0008CX@mauve.mrochek.com>
Date: Wed, 16 Aug 2006 16:44:18 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 16 Aug 2006 14:20:51 -0700 (PDT)" <Pine.LNX.4.62.0608161414110.26667@sokol.elan.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format="flowed"
References: <E1GCknR-0004hD-Jt@stiedprstage1.ietf.org> <44E1D050.F9A@xyzzy.claranet.de> <44E1EAEF.3030505@hxr.us> <44E2C737.8000402@alvestrand.no> <Pine.LNX.4.62.0608161414110.26667@sokol.elan.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
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
> 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. > 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. I believe SIP is specified to use exponential backoff when running over UDP. There certainly is plenty of discussion of this stuff throughout RFC 3261, and the words "retransmit" and "congestion" appear plenty of times in the document. But let's suppose for a moment that no previous IETF protocol had ever discussed congestion control or retransmits or anything similar when using UDP. So what? This doesn't mean these aren't issues that a new protocol should deal with. It doesn't mean we can simply ignore these issues and expect things to just work. There are plenty of things we know now that we didn't know just a few years ago, and as a result the list of details we know are best dealt with in order to have a successful protocol has grown, and will probably continue to grow. The argument that "so and so done some years ago didn't do foo so I don't need to either" doesn't hold water IMO. RFC 2914 was written for a reason, and didn't become a BCP because it sounded nice to call it that. > Session control is why we have TCP. No, we have TCP because it is useful to have a standardized stream transport that takes care of the various transport-layer tasks, including but not limited to session control, so we don't have to reinvent these wheels in every application. And we have UDP because TCP isn't the right choice for every application out there. But UDP is in some senses a sharper tool than TCP, and requires extra care when it is used. I take no position on whether or not the use of UDP is appropriate in this case. But if it is, congestion control issues need to be addressed. Ned _______________________________________________ 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