Hi Folks,
Here is clarification of what Magnus wants. We have so far received
Eliot's proposal but I don't think that addresses the concern.
I would like to hear from everyone. Do we want to push back on Magnus, or
can someone propose some text around this?
Thanks,
Chris
---------- Forwarded message ----------
Date: Fri, 06 Jul 2007 18:08:12 +0200
From: Magnus Westerlund <[EMAIL PROTECTED]>
To: David Harrington <[EMAIL PROTECTED]>
Cc: Chris Lonvick <[EMAIL PROTECTED]>, Lars Eggert <[EMAIL PROTECTED]>
Subject: Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd)
Hi David,
I think you are missunderstanding things here. But thanks for protesting and
not accepting crap. But let me make clear what I actually think is needed in
regards to syslog to make it a working protocol to deploy.
First, this starts as an issue with TLS over TCP and the syslog base protocol.
It can also arise teorethically for UDP, but as I understand not in practice
for todays usage. When you are using TCP, in case the syslog sender generates
events at an rate that is higher than available rate over the path used there
will be build up of a queue. So I would like to have some words somewhere
saying what you do when you build up a queue of messages that should be
transmitted, but the queue simply keeps growing. What do I do? To me this
situation implies that one starts discarding syslog messages and starts with
the least important ones. So I would like to have a paragraph on this.
I also included UDP in this in the case that you actually have reserved or
determined that syslog is allowed to use a particular amount of bandwidth, but
not more. In this case it could be possible that one implements a rate limiter
and run into exactly the same issue as for TCP.
Please do understand that if syslog was designed from scratch today it wouldn't
get awy without a congestion control that guarantees that it isn't missbehaving
in any situation. But being an "old" protocol we are accepting less than that.
However, we do require it to contain the limitations and assumptions that it
can be safely operated with. Using it as it currently is used is not an issue
because the networks it is used in has many magnitudes more bandwidth that
syslog generates. However, what would happen if some one starts using syslog in
low-powered, low-bitrate sensor network for carrying some information. In that
situation syslog becomes a potential threat to the stability of the network as
it doesn't react at all to congestion if run over UDP. Network failures are
also sitation that are problematic to ensure that the inteded resources are
available. Thus we do like to protect the utility of what resources do exist.
So the repeat:
Please seriously consider adding a paragraph about how one can thinn a queue of
syslog messages in the base protocol. This as I think it potentially applies to
any transport.
Also consider when updating the UDP draft and adds what has been discussed with
Lars, to add a single sentece with a reference the above paragraph as a method
to keep the traffic within the allowed resources.
Regards
Magnus
David Harrington skrev:
Hi Magnus,
Syslog is a fire-and-forget protocol. We have no feedback mechanism
that permits us to recognize congestion and rate limit traffic based
on that feedback.
Syslog is not a brand new protocol; it is widely used in the industry,
and other aspects of standardization has been handled through POSIX
and BSD standardization. The industry has expressed no interest in
making this a two-way protocol. This protocol is widely used by
operators, amd I have seen no demand from operators to make this a
two-way protocol, or any demand to resolve congestion control for
syslog, because congestion caused by syslog apparently is not a
problem in the real world.
We had discussion of rate-limiting during the IETF Last Call. We
actually had suggestions for ways to rate-limit syslog in the earlier
document, but the IETF community rejected our having that text in the
document because syslog is a fire-and-forget protocol, so there is no
reliable mechanism for detecting congestion. The IETF commmunity did
not ask us to make syslog two-way, so we could add rate limiting to
the protocol; they asked us to keep syslog working as is, and remove
the unreliable recommendations to rate limit.
You are placing a whole new requirement, that no implementers or
operators are asking for, on a protocol that is already widely
implemented and deployed. Where is the customer demand for this?
I am concerned you might drive the syslog community to not work within
the IETF, where they came to develop a standard message format and a
secure transport, not to change the basic nature of the protocol.
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED]
----------------------------------------------------------------------
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
