Subject: RE: [Syslog] #2, max message size

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 30 Nov 2005 18:37:10 +0100

John,

the issue is the simplex nature of syslog. With syslog (other than with
almost all other protocols), you send a message and need to *hope* that
the recipient can receive it. There is also no negotiation phase. So you
need to send it blindly. For example, if you send an IHE 2K message, but
the receiver does just support 1K, you will loose 1K without knowing it.
As such, it is vital to know at least a "safe size" that you can use and
know that it can be processed (if it makes it to the recipient). We
selected 480 octets because that fits into an unfragmented UDP packet in
any case. I know that's too few for IHE, but for network management - an
important use case for syslog - this is very often sufficient. This is
the reason why a simplex protocol like syslog (send it and forget it ;))
should provide some guidance about lower limits. Keep in mind that there
is NO upper limit - this is done in the transport mappings and the
implementations. So if you need 32K for IHE, that is perfectly well
(-transport-UDP, I think, suppport 64K - but you know the practical
limits).

Does this clarify?

Rainer

> -----Original Message-----
> From: Moehrke, John (GE Healthcare) [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2005 6:13 PM
> To: Rainer Gerhards; Darren Reed
> Cc: [email-masked]
> Subject: RE: [Syslog] #2, max message size
> 
> Shouldn't the MTU be defined by the binding to the transport? 
> I fail to
> see why the protocol, unbound to a transport, needs to have a limit. 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> > Sent: Wednesday, November 30, 2005 11:01 AM
> > To: Darren Reed
> > Cc: [email-masked]
> > Subject: RE: [Syslog] #2, max message size
> > 
> > Darren,
> > 
> > I violently object your argument and leave it up to the 
> rest of the WG
> > what should be done. I respect your argument, but I do not like to
> > re-iterate this forever.
> > 
> > One time we have discussed this was in October 2004:
> > 
> > http://www.syslog.cc/ietf/autoarc/msg01289.html
> > 
> > If you browse the archive, you will find several other 
> ocasions where
> > this was discussed.
> > 
> > What's your actual recommendation? Do not say anything and 
> > leave it the
> > implementor to guess what is OK? After all, its the implementor's
> > problem if the message can not be transmitted. Or do you prefer to
> > define an API where the lower layer tells the upper layer what
> > capabilities it has? Maybe MTU discovery? Or an app-level 
> ack? I think
> > all of these options have already been discussed during the 
> > past years.
> > What is now in is a (fragile) consensus, but if only you do 
> > not like it,
> > I think we should go ahead and leave an unhappy Darren 
> > behind. If only I
> > insist on it, we can also go ahead and leave an unhappy 
> Rainer behind.
> > But we need to go ahead!
> > 
> > Rainer 
> > 
> > > -----Original Message-----
> > > From: Darren Reed [mailto:[email-masked]] 
> > > Sent: Wednesday, November 30, 2005 4:49 PM
> > > To: Rainer Gerhards
> > > Cc: [email-masked]
> > > Subject: Re: [Syslog] #2, max message size
> > > 
> > > > Darren,
> > > > 
> > > > > The only place a message size limit should be specified is in 
> > > > > a transport
> > > > > mapping.  If it's in -15 then it should be removed.  Limits 
> > > > > of all sizes
> > > > > and types do nothing but contribute to aging of a protocol.
> > > > 
> > > > -protocol-15 is a compromise after a very long 
> > discussion. It says:
> > > > 
> > > > -----
> > > >    A receiver MUST be able to accept messages up to and 
> > > including 480
> > > >    octets in length.  For interoperability reasons, all receiver
> > > >    implementations SHOULD be able to accept messages up to 
> > > and including
> > > >    2,048 octets in length.
> > > > 
> > > >    If a receiver receives a message with a length larger 
> > than 2,048
> > > >    octets, or larger than it supports, the receiver MAY 
> > discard the
> > > >    message or truncate the payload.
> > > > -----
> > > > 
> > > > I think this text is useful. It keeps the door open for any size
> > > > messages while still allowing it to be restricted by 
> the transport
> > > > mappings and individual implementations (e.g. on 
> low-end embedded
> > > > devices). It cautions implementors against being too 
> > > verbose but also
> > > > sets a lower limit that each implementation can assume to 
> > > be received.
> > > > 
> > > > I think we should continue to use this text. Do you agree?
> > > 
> > > No.  That text doesn't belong in this draft.
> > > 
> > > Darren
> > > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 

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

---

From: Darren Reed <[email-masked]>
Date: Thu, 1 Dec 2005 05:36:42 +1100 (EST)

> need to send it blindly.

What you're failing to grasp here is that syslog-protocol, by itself, does
not define how it is to be used.  All it is doing is defining a message
format.  With a layered approach to defining syslog we need to split out
documentation that is specific to an implementation (such as the maximum
message size) from the definition of the protocol messages themselves.

In your charter you have a "syslog-protocol over UDP".  So any talk in
syslog-protocol about maximum message size is going to be redundant for
UDP.  Using syslog-protocol over TCP is not yet on the radar so anyone
making assumptions about maximum size is doing so at their own risk.
If they choose 4K or 8K or 1K as the maximum size, that's up to them.

If you really want to get back to basics, I'd not accept any maximum
message size that was bigger than 490 bytes (576-14-64-8) as this is
the largest frame size that IPv4 is *required* to reassemble.  Either
you remove the maximum message size from syslog-protocol or drop it
to 490 but leave it open to refining by transport definitions.  Yes,
I'm well aware of 490 being "too small" for some practical purposes
but you're not thinking clearly if you want any sort of maximum size
in syslog-protocol and this needs to be reinforced.

Darren

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 30 Nov 2005 11:07:40 -0800 (PST)

Hi Folks,

We need to resolve this one.  I've heard from Rainer and a very few 
others.  I'd like to hear from more people on this.  Choose one:

__  The maximum message length needs to be defined in syslog-protocol.

__  The maximum message length should be defined in the transport
     documents.

__  I have a different idea....

Please VOTE NOW!

Thanks,
Chris

---

From: Carson Gaspar <[email-masked]>
Date: Wed, 30 Nov 2005 14:13:06 -0500

> others.  I'd like to hear from more people on this.  Choose one:
...
> __  The maximum message length should be defined in the transport
...

It's a transport issue.

We may want to specify a "minimum maximum" - i.e. a syslog receiver MUST be 
able to handle messages of at least n octets, but that probably also 
belongs in the transport doc.

-- 
Carson

---

From: "Andrew Ross" <[email-masked]>
Date: Thu, 1 Dec 2005 11:41:16 +1300

My vote is for the way Rainer has worded it now. Specify the minimum msg
size in syslog-protocol and define max message size in the transport
documents.

Cheers

Andrew

Hi Folks,

Please VOTE NOW!

Thanks,
Chris