On Wed, Dec 18, 2002 at 07:11:05PM -0800, Darren New wrote: > Rodney Thayer wrote: > > AND it introduces more processing in between your payload and TLS. > > The point is, BEEP adds a layer of overhead that people are debating the > > value of. > > The debate was already dealt with ages ago, and modifications to the > profile were made to minimize the overhead. The amount of processing > overhead introduced is roughly the same order of magnitude as the > processing overhead of using TCP instead of UDP, I would guess. > Basically, adding two mod-2^32 numbers together and converting them to > strings of ASCII digits is the extent of it. What part of the overhead > do you think is unacceptable, specifically, and why do you think that?
BEEP is not a bad protocol, it offers features that other protocols implement on their own (think of SSH2 and its channels). What we are questioning is right now is the need for negotiation. Syslog infrastructures as deployed today are very simple: - each client sends messages to one or more destinations There's no negotiation going on right now. There's nothing the sender or client sides must agree on. Not even the maximum length of messages, not whether to use TLS or not. These are defined externally, in the configuration of the syslog implementation. You might raise the fact that this causes management problems, as each decision (e.g. configuration option) must be distributed to each syslog endpoint (be it sender, relay or collector), and that a given point-to-point syslog stream works if and only if both sides are configured the same (to use TLS, to use RFC3339 timestamps and so on) This might become a real problem if you have thousands of devices, but these problems are minor compared to the fact that we are still using UDP and messages limited to 1024 bytes. Another feature that BEEP provides us is the notion of channels, e.g. it lets you multiplex several full-duplex channels into the same TCP session. For this it uses its own windowing, has its own channel control messages etc. This does not mean too much to syslog right now either. We can use several TCP streams if we need to. The possibility of requesting parts of the syslog stream in a separate channel might be useful in the future, but the control messages to achieve this needs to be defined. The problem with RFC3195 is that it provides solutions for the future, but does not solve our current problems. Plain TCP transport is supported in more-and-more implementations but they not necessarily interoperate, even end devices support it sometimes: - kiwisyslog - msyslog - nsyslogd - syslog-ng - Cisco PIX And I'm sure I've forgotten some. These should interoperate, most of them do I guess, but an RFC would help in this area right _NOW_. The BEEP solution might be the future, but first it needs implementations, and further updates that makes the overhead explainable. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
