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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf