Subject: RE: [Syslog] RE: Message format

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Nov 2005 09:33:09 +0100

Andrew & WG,

a follow-up to my own posting, just some extra information. 

> > When mapping over plain TCP I believe we should limit the 
> > total message size
> > to 65507 bytes (to keep it compatible with UDP) and delimit 
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Anton and other already cautioned against using too-large UDP message
sizes. I just want to throw in some of our practical experiences. I've
done some testing on Windows and Linux, and the result is that UDP
practical maximum tends to be around 4K. It is documented here:

http://www.monitorware.com/Common/en/articles/ihe-syslog.php

Of course, other software might modify the IP stack with different
parameters. The rsyslogd I have tested with is derived from stock Linux
syslogd, so that quite popular system is experiencing the same issue.

While I always tell we need to allow larger-size messages, we need to be
very careful when thinking about UDP. My testing did not even look into
message loss and out-of-order delivery. For UDP, I consider the
practical upper limit to be 4K. 

Rainer

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Nov 2005 16:50:10 +0100

Darren,

I fully agree with you. My understanding is that John just needs to
transmit text in the MSG part which co-incidently "looks like" XML It
must, however, a bit longer than 1K, which is backed by the current
state of discussion. I, too, strongly object mandating XML or anything
else formatted in a specific way (other than structured data). I have
begun to become very sceptic about RFC 3195 (again, I have implemented
it). I think we need to very carefully evaluate it *after* we have
finished the base work.

BTW: my recent findings about the total incompatibility of various
well-deployed implementations are a strong point that we need to
standardize the basic format. But just what the bare essentials - and
the quicker, the better. Already a lot of time has passed.

Rainer

> -----Original Message-----
> From: Darren Reed [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 4:44 PM
> To: Rainer Gerhards
> Cc: Moehrke, John (GE Healthcare); Darren Reed; 
> [email-masked]; [email-masked]
> Subject: Re: [Syslog] RE: Message format
> 
> > I think this is a valid use case. Syslog traditionally has not only
> > focussed on network management but has always been used for
> > application-layer event notifications. I think what John asks for is
> > within our charter and doesn't even require any change to 
> what we have
> > been discussing so far.
> 
> So long as XML in the message can be satisfied by saying it is part
> of the "MSG" section, then yes.  I don't believe there are any planned
> restrictions on what the text content of "MSG" can be.
> 
> Otherwise we're just going back down the road of 3195.
> 
> If John wanted to see XML in syslog formalised, then my vote would for
> it to be a follow on draft that documented a particular SD-ID as the
> means for indicating the MSG was expected to be XML.
> 
> But I cannot emphasise strongly enough that it is not appropriate for
> this group to take on syslog and XML, beyond what exists in 3195, at
> the present time.  We need to focus on the charter and achieve a basic
> set of goals first before moving on to things like this.  This isn't
> to say that it won't be addressed, but not here and now.  If this puts
> you, John, in uncertain land for the time being then I think that has
> to just be accepted with an understanding that it can be redressed at
> some point in the future, even if it doesn't make our current charter.
> 
> Darren
>

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Wed, 23 Nov 2005 11:43:50 -0500

Darren:

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Darren Reed
> Sent: Wednesday, November 23, 2005 9:09 AM
> To: Moehrke, John (GE Healthcare)
> Cc: [email-masked]; [email-masked]
> > To all,
> > The view that syslog must only be used to transport "human readable 
> > syslog messages" is disturbing. Is this the view of the syslog 
> > community?
> 
> At present what we're concerned with is a logging facility 
> that does generate and consume human readable messages.

How do you define "human readable"? Is assembly code human readable? :)

Maybe you implied it should be limited to printed characters... well any octet can be represented in print in some shape or form (say by hex), and I thought it is out of scope how stuff is printed, displayed or stored on disk for the on-the-wire protocol. If you limit it to "language" characters, you don't really want to exclude control characters such as tabs. 

I really don't think there is a good reason to exclude any octet in the payload. It would be like saying you can't send certain octets in email (including binary attachments) because it must be human readable.  Well, let the two sides figure out what is readable to them and just transport the payload with appropriate agreed-upon header.    

At a minimum, I hope that if we put terms like "human readable" into the charter, we would be clear about what they mean.  

Also consider that programmatic parsing and interpretation of syslog messages is common-place today and must continue. For example, gazillions of systems (home grown and commercial) have been built around Cisco's use of syslog to do automated fault detection, correlation, etc. Use google to find examples. 

In summary, I am not comfortable with "human readable" restriction going into the charter.  

Thanks,
Anton.   

> 
> At some point in the future, when we have agreement on the 
> human readable version, then we can consider what to do with 
> messages that aren't human readable.
> 
> So while I accept your assertion, addressing it is out of 
> scope for the current discussion.  We have smaller fish to 
> fry, first, before attempting the big ones.  Trying to solve 
> "all the problems" is what got this group into the situation 
> we are in now.  We need to take a step back and focus on 
> resolving smaller and more well defined problems before 
> looking at a "grand unified logging protocol" (GULP).
> 
> Nothing lasts forever, not even standards.
> 
> Darren
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Nov 2005 17:47:52 +0100

Darren, Anton:

While  I agree with Darren we should NOT specify any specfic format of
MSG, I agree with Anton that we should NOT put the wording "human
readable" into the charter.

Rainer

> [mailto:[email-masked]] On Behalf Of Anton 
> Okmianski (aokmians)
> Sent: Wednesday, November 23, 2005 5:44 PM
> To: Darren Reed; Moehrke, John (GE Healthcare)
> Subject: RE: [Syslog] RE: Message format
> 
> Darren:
> 
> Maybe you implied it should be limited to printed 
> characters... well any octet can be represented in print in 
> some shape or form (say by hex), and I thought it is out of 
> scope how stuff is printed, displayed or stored on disk for 
> the on-the-wire protocol. If you limit it to "language" 
> characters, you don't really want to exclude control 
> characters such as tabs. 
> 
> I really don't think there is a good reason to exclude any 
> octet in the payload. It would be like saying you can't send 
> certain octets in email (including binary attachments) 
> because it must be human readable.  Well, let the two sides 
> figure out what is readable to them and just transport the 
> payload with appropriate agreed-upon header.    
> 
> At a minimum, I hope that if we put terms like "human 
> readable" into the charter, we would be clear about what they mean.  
> 
> Also consider that programmatic parsing and interpretation of 
> syslog messages is common-place today and must continue. For 
> example, gazillions of systems (home grown and commercial) 
> have been built around Cisco's use of syslog to do automated 
> fault detection, correlation, etc. Use google to find examples. 
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 24 Nov 2005 09:22:36 +0100

Happy thanksgiving to all US list members! I hope you have better to do
than read my postings today. I'll send them anyhow looking forward to a
healthy discussion next week :)

<comment inline>

Rainer

> From: Andrew Ross [mailto:[email-masked]] 
> 
> I concur on the message size issue. Let's leave it as it 
> stands until we get
> to a TCP mapping. Can you mention in your document that the 
> real life max
> UDP size was found to be 4K bytes? I think this is a valuable 
> finding and
> would save a lot of hair pulling on the part of implementers.

This is an item for Anton's UDP transport mapping. Please notet that I
did no extensive analysis and there are probably ways to increase the
MTU. I have not looked at this because I was interested in what you can
expect in "the usual case". I think Anton has done some more work in
this regard and can eventually provide further insight.

> Cheers
> Andrew
> [mailto:[email-masked]]
> On Behalf Of Rainer Gerhards
> Sent: Wednesday, 23 November 2005 10:00 p.m.
> To: [email-masked]
> Cc: [email-masked]
> Andrew,
> on the size: Though I have some concerns, I can agree with 
> your point of
> view. In fact, one of the syslog-protocol revisions had a mechanism
> called multi-part messages. This could be utilized. Maybe we 
> should do a
> separate spec on "large size messages". That wouldn't be too 
> much effort
> and be a truely optional feature (I even think we could simply carry
> over the text from that draft version).
> 
> What I am currently concerned about is putting this size issue to a
> rest. I think the compromise is good enough, especially as we 
> do NOT yet
> specify a plain tcp mapping (we even don't know if we will ever get
> consensus to do that). That means the currently proposed text 
> keeps the
> options open to do anything we might later decide. And it 
> acutally puts
> a hard limit to roughly 64K by the fact that only UDP is 
> supported. As I
> have outlined in another mail, that practical limit seems to 
> be more 4K
> than 64K.
> 
> Given that situation, I strongly suggest not to get another 
> round of max
> size discussion.
> 
> I think we urgently need now a consensus on the lowest denominator and
> get that consensus published. Else we will be discussing and 
> discussing
> but never achive any milestone. I like the approach of 
> baby-steps, which
> will give us something usable after each step. The core thing 
> we need to
> do is have a format specification including layered architecture) that
> allows us to build on. Then, I think, we can focus on specific issues.
> 
> Rainer
> 
> > From: Andrew Ross [mailto:[email-masked]] 
> > Sent: Wednesday, November 23, 2005 9:51 AM
> > To: Rainer Gerhards
> > >> Mapping over UDP should be limited to a single message 
> per packet.
> > >I agree on that. If we need an ultra-compact UDP delivery, we could
> > >later add it in a separate transport mapping.
> > 
> > Yes, good idea. I doubt anyone will ever want to do this, or 
> > at least go to
> > the effort of trying to get it drafted into an RFC ;-)
> > 
> > >> each message
> > >> stream with an LF, or CRLF. Either delimiter would work for me.
> > 
> > >I would prefer not to restart the size discussion at this 
> > point. I think
> > >the current compromise (everyone must support 2K, anyone 
> > might support
> > >as much as he likes) is sufficient for most, if not all, 
> > cases. I would
> > >not like to see an application to become non-compliant just 
> > because it
> > >needs to transmit 65508 bytes inside a message.
> > 
> > <SOAPBOX>
> > I realise this should have been brought up earlier in the 
> > draft process,
> > however, I would really like to see a limit on the message 
> > size so that it
> > is directly compatible with UDP. If we allow an opened ended 
> > message size,
> > people *will* use it for non syslog related things. I feel 
> > that any message
> > longer than will fit into a UDP packet should be broken into 
> > two or more
> > separate messages by the sender, even if sent over TCP. This 
> > allows me to
> > allocate a maximum known buffer size for incoming TCP 
> > messages. There is a
> > potential for huge messages filling the memory and memory 
> > buffer overflows
> > happening if the messages are not limited in size. "Syslog" 
> > is meant to be a
> > human readable system log message. Anything longer (including 
> > binary crash
> > dumps or other things people misuse syslog for) should be 
> broken into
> > separate messages by the sender, or sent over a different protocol.
> > </SOAPBOX>
> > 
> > I think we should keep syslog simple and flexible, but not at 
> > the expense of
> > making it handle things it was never meant for. If a message 
> > needs to be
> > broken into many chunks, the SD-ID tags could be used to tie all the
> > messages together again by the parser. The syslog receiver or 
> > relay will
> > just handle them as separate messages and not even know they 
> > were split.
> > This makes things so much simpler.
> > 
> > Cheers
> > 
> > Andrew
> > 
> > 
>