This topic may be being driven by draft-ietf-tsvwg-udp-guidelines-02 by Eggert/Fairhurst.
Worth a peruse; quoting out of context (is syslog bulk or not?), it contains such as "If an application or upper-layer protocol chooses not to use a congestion-controlled transport protocol, it SHOULD control the rate at which it sends UDP messages to a destination host. "Applications that perform bulk transmission of data to a peer over UDP SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC3448], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. "A second class of applications cannot maintain an RTT estimate for a destination, because the destination does not send return traffic. Such applications SHOULD NOT send more than one UDP message every 3 seconds, and SHOULD consider if they can use an even less aggressive rate when possible." and on the checksum issue "Applications SHOULD enable UDP checksums, although [RFC0793] permits the option to disable their use. "A special class of applications derive benefit from having partially damaged payloads delivered rather than discarded when using paths that include error-prone links. Such applications can tolerate payload corruption and MAY choose to use the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of basic UDP" Tom Petch ----- Original Message ----- From: "Chris Lonvick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 11, 2007 4:16 PM Subject: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
