Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd)

["tom.petch" <cfinss at dial.pipex.com>]

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" <clonvick at cisco.com>
To: <syslog at ietf.org>
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 <magnus.westerlund at ericsson.com>
> To: David Harrington <ietfdbh at comcast.net>
> Cc: Chris Lonvick <clonvick at cisco.com>, Lars Eggert <lars.eggert at nokia.com>
> 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
> >  dharrington at huawei.com
> >  dbharrington at comcast.net
> >  ietfdbh at comcast.net
> >
>
> --
>
> 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: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> Syslog mailing list
> Syslog at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog


_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog