Subject: [Syslog] Discuss - Congestion Control

From: Chris Lonvick <[email-masked]>
Date: Thu, 5 Jul 2007 07:58:44 -0700 (PDT)

Discuss - Congestion Control

Magnus: But what I think is needed here is some clear and normative 
requirement on how to avoid and limit congestion. First of all I would 
like to see a restriction on the applicability of this transport to within 
a controlled environment unless the rate is capped to a level that is TCP 
friendly or the full path is provisioned to handle the traffic. There 
should also be
a discussion on how one rate limits SYSLOG traffic.

Magnus: If any higher rates of packets are to be sent over best effort 
networks then a feedback mechanism is needed. That would probably need to 
include forward path UDP packetization layer with sequence number to 
enable loss detection. Complemented with feedback traffic to enable rate 
control of outgoing traffic. That could also resolve the PMTUD issue.

Lars:
draft-ietf-syslog-protocol-21, Section 8.5., paragraph 2: >    It may be 
desirable to use a transport with guaranteed delivery to
>    mitigate congestion.
   Reliable delivery and congestion control are orthogonal features. A
   reliable transport will not necessarily have congestion control, and
   vice versa.

Lars:
draft-ietf-syslog-protocol-21, Section 8.5., paragraph 3:
>    It may also be desirable to include rate-limiting features in syslog
>    originators and relays.  This can reduce potential congestion
>    problems when message bursts happen.
   This is too weak a statement on congestion control. See DISCUSS above.

Lars:
Given the issues that the UDP transport has with congestion control, 
security and fragmentation, I'd like the document to
recommend the TLS-based transport over the UDP-based one for general use, 
i.e., when the network is not specifically
provisioned for this type of traffic.

Prposed Resolution:

+ Place text in syslog-protocol, syslog-transport-tls, and 
syslog-transport-udp to state that
   - udp transport is to be used only where the network is specifically
     provisioned for this type of traffic,
   - tls is to be used in all cases where congestion issues may be a
     concern.

+ Remove the text in syslog-protocol which states that reliable delivery
   will mitigate congestion.

Response from Lars:
I'd like to see the actual text changes, but this proposal exactly 
captures what I'd like to see happen.

Response from Magnus:
This mostly addresses my concerns. I still think there is one major issue 
around this with congestion control. And that is
some description on how to rate-limit your traffic. Either in UDP to some 
pre-configured threshold and in the case of TLS
over TCP the rate actually available. There can occur situations where the 
amount of generated data will be larger than
what can be transfered. How does one resolve this? I think it probably 
needs to be more text in syslog-protocol spec about this. How to use scope 
and prio to determine which messages to throw away or queue up (within 
limits).

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 Jul 2007 19:21:22 +0200

Chris, Magnus,
> Response from Magnus:
> This mostly addresses my concerns. I still think there is one major 
> issue around this with congestion control. And that is
> some description on how to rate-limit your traffic. Either in UDP to 
> some pre-configured threshold and in the case of TLS
> over TCP the rate actually available. There can occur situations where 
> the amount of generated data will be larger than
> needs to be more text in syslog-protocol spec about this. How to use 
> scope and prio to determine which messages to throw away or queue up 
> (within limits).
>

Most sources of potentially voluminous syslog messages have a rate limit 
mechanism already in as much as they will aggregate messages (the old 
"Last message repeated N times" thing).  I propose that we add some 
wording along the lines of the following in syslog-udp:

    syslog generator implementors must be mindful of the downstream
    resources their messages will consume, both from a network and
    server standpoint.  A single syslog source that has the capability
    to produce a flood of messages should aggregate and rate limit them
    in some appropriate fashion.  An event count combined with rate
    limiting has been used very successfully in the past.

How about that?