Anton: the max message size is a frequent topic on this list. I thought we had reached a full agreement previously, but after some extensive archive searching, I could not find a final concensus. The closest thing to a concensus was discessed in this thread:
http://www.syslog.cc/ietf/autoarc/msg00855.html I recommend to review it, it applies to this issue here, too. The thread ended somewhere around the implicit concensus that fragmentation and long messages are needed. > I think that the 1024 bytes limit is rather arbitrary (CLR?). It is a historical limitation. Though I know that we already have broken with backwards compatibility, I really, really do not like to remove this limitation. One important reason is that I think we should not come up with a spec that does not even remotely look like traditional syslog. We are already close to this point. Removing the size limitation will get us over the edge. This will probably cost us a lot of momentum. I am already concerned if implementors will pick up -protocol, because it looks very different. I am really afraid of changing this... > It does > not always avoid fragmentation, nor does it provide for efficient > transfer when larger messages need to be transmitted. > > I assume we can't completely avoid fragmentation with > -protocol, because > that would require a very small message size limit, and we will still > probably assume Ethernet. Fragmentation is not inherently bad except > for some firewalls of vendor we won't mention which used to drop > fragmented UDP packets at will instead of reassembling them (I think > they call those stateless firewalls). But that's just broken - if they > need UDP port info, they must reassemble packets. My experience is that there is always trouble with fragmented UDP. I can't proove it with hard arguments, though. But it is a strong feeling. I have to admit I am not 100% sure what the UDP spec says: If a UDP packet becomes fragmented (due to MTU), is it guaranteed that the packet will be re-assembled by the receivers IP stack before it is passed up to the app layer? What if a fragment is missing? Will the whole packet be discarded by the stack (UDP is best effort, after all...)? I would appreciate if someone saves me the time of reading the UDP RFCs... > > In IPv6, the clients learn the MTU of the network and must do > fragmentation themselves. So, unexpected fragmentation should be less > of an issue and efficiency will be achieved by discovering > optimal MTU. > It almost seems like we are re-inventing the IP fragmentation with out > support for syslog multi-part messages. > > Solution proposal: > > How about we just set the size limit at around 64Kb (max UDP datagram > size) and drop the whole fragmentation feature? Based on previous discussion on the WG and other forums, I do not support this. Fragmentation in -protcol is lightweight an truely optional. If you don't need it, don't use it. It just gives you a way to transmit "oversize data" in a standard way. I have to admit I am insisting on this because we again could not create fully compliant products, simply because 64K is not enough in some rare, but to-be-supported, cases. Eventually others would have the same issue. > At least for the > foreseeable future 64Kb should be sufficient (although I am sure this > won't be enough forever). Windows Event Log records can become larger (mainly if binary data is transmitted - very few of our customers insist on this). > Together with this, we can > recommend that in > order to avoid IP fragmentation and potential firewall, > performance and > reliability issues, it is recommended that on the Ethernet > users strive > to restrict most syslog messages to 512 bytes. With the added header fields, the potential 255 byte FQDN in the header and the structured data elements, payload can be a very limited set of these 512 bytes ... but I still agree, it should be fine for most messages. > This > recommendation will > also potentially improve readability of messages. By removing > the syslog > fragmentation from -protocol, we will leave fragmentation in one place > -- IP and allow for more efficient syslog implementations. I don't like this for the reasons stated above, mainly because of the insufficient max size. I am also not sure if it can cause troubles with other transport mappings (syslog over snmp trap was already discussed recently in this WG). What does the rest of the WG think? Rainer > > Anton. > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 11, 2004 11:57 AM > > To: [EMAIL PROTECTED]; Anton Okmianski > > Subject: syslog message size and fragmentation > > > > > > Hi WG, > > > > I had an off-list discussion with Anton that lead to the > > discovery of a new issue in -protocol, that of message > > fragmentation. -protocol specifies a message size limit of > > 1024 characters, but also assumes that message of this size > > can always be transmitted without (transport) fragemention. > > In the real world, datagram based transport mappings will > > probably not be able to assure that the message will not > > become fragmented. The MTU can at least be as low as 576 bytes. > > > > Must this issue be addressed in the context of -protocol? If > > so, what is the best solution? > > > > Thanks, > > Rainer > > > > > >
