I understand the arguments that have been used, yes. I understand that in the end there will be a small practical MTU when transmitting over UDP (I would like it to be the 4k that your experiments determined, not 2K, or worse 480). I don't argue with that truth. I very simply fail to see why this is a syslog-protocol layer and not a transport-binding specification.
Side comment, not necessary for the document at hand: I also don't understand what I would do different if I could determine (in your words negotiate) what the MTU actually was. I have a message that needs to be sent, it will either make it or not. Knowing a dynamically determined MTU is of no value as I can't make my message smaller, it is what it is. If it gets fragmented, I hope it will be reassembled. If it is big, I hope that the receiver offers up a big enough buffer to it's socket library. It is all hope at this point. I am ok with hope, I just don't want you to limit my ability to hope. John > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 30, 2005 11:37 AM > To: Moehrke, John (GE Healthcare) > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] #2, max message size > > 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 PROTECTED] > > Sent: Wednesday, November 30, 2005 6:13 PM > > To: Rainer Gerhards; Darren Reed > > Cc: [EMAIL PROTECTED] > > 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 PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > Rainer Gerhards > > > Sent: Wednesday, November 30, 2005 11:01 AM > > > To: Darren Reed > > > Cc: [EMAIL PROTECTED] > > > 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 PROTECTED] > > > > Sent: Wednesday, November 30, 2005 4:49 PM > > > > To: Rainer Gerhards > > > > Cc: [EMAIL PROTECTED] > > > > 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 protected] > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
