RE: [Syslog-sec] UDP message size issue proposal

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Anton,

I agree to your conclusion.

Although I am the one who always voted for larger sizes, the discussion
has shown that this yields to unnecessary complexity. I can satisfy my
needs with a vendor-extension structured data element, which I think
shows the flexibility of the new drafts.

So I support your move. I would tend to even remove the transport
version header. If there is need to, we could always include that in a
later release (e.g. "v1", which would make it clearly distingshable from
the current frame format). I see little need to do so, though.

Regarding -protocol, I think we should still keep an upper limit in the
spec. Even I don't see any reason why a syslog message should go above
16MB. So for -protocol, I propose the following new text:

####
5.1  Message Length

   The maximum length of any syslog message is 16,777,216 octets.  Any
   receiver receiving a larger message MUST discard the message.  A
   diagnostic message SHOULD be logged in this case.

   A receiver MUST be able to accept messages that are 480 octets (or
   less) in length.  A receiver SHOULD be able to accept messages that
   are 65,535 octets (or less) in length.  It is RECOMMENDED that
   receivers be able to accept messages up to the maximum message length
   of 16,777,216 octets.

   If a receiver receives a message within the maximum length, but with
   a length larger than it handles, the receiver MAY discard or truncate
   it.

   A transport mapping MAY define a maximum length below the one
   specified here.  Each transport mapping MUST support a maximum size
   of 480 octets or more.
####

If there is agreement on this, I can post a new version of -protocol.
That version will also include some changes made thanks to Andrew Ross
comments (sent via private mail). I have finished this version. It is
available for immediate posting, but I would like to wait for agreement
on the size issue (at least if that can be reached quickly).

Rainer

> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org 
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of 
> Anton Okmianski
> Sent: Tuesday, October 12, 2004 11:25 PM
> To: syslog-sec@employees.org
> Subject: [Syslog-sec] UDP message size issue proposal
> 
> Hi!
> 
> Sorry for a long delay on this issue - I was on a 2 week 
> vacation.  I have spoken with a number of TCP/UDP/IP experts 
> regarding the sizing issue.  I am ready to propose the 
> following changes:
> 
> 1. Syslog-protocol will state that the max message will be 
> defined by the transport layer.  
> 
> 2. Syslog-transport-udp will support messages up to maximum 
> UDP datagram size of 64K. UDP is a very bad choice for large 
> message transmissions, so it does not make sense for us to 
> stretch it by adding our own fragmentation without other 
> transmission control features such as found in TCP.
> 
> 3. Syslog-transport-udp will rely on IP fragmentation and we 
> will get rid of "proprietary" fragmentation which was 
> designed to handle messages over 64K and deal with various 
> non-compliant network hosts.    
> 
> 4. Syslog-transport-udp will recommend sending messages 
> within the boundaries of prevalent MTU size on a given 
> network to be safe. It will recommend Ethernet's 1500 bytes 
> less headers and will draw reader attention to the minimum 
> MTU size hosts on the network are required to support for 
> IPv6 (576 bytes) and IPv6 (1280 bytes).   
> 
> 5. Path MTU discovery may not work robustly and some TCP/IP 
> stacks may not support UDP packets of full 64K size and 
> truncate them.  We will mention this and bite this bullet.  
> We should not restrict the protocol due to incompliant 
> implementations because it is a moving target and penalizes 
> compliant implementations with extra overhead. The above size 
> recommendation would partially deal with this, but leave the 
> final choice up to the administrator.      
> 
> 6. We will get rid of most syslog transport headers for UDP 
> as they will no longer be needed.  The only thing that will 
> be left is the transport protocol version prefixed to every 
> syslog message.  Should we even bother with that?  
> 
> This is a major change to the syslog-transport-udp.  I'd like 
> to get positive feedback before I proceed with this update.  
> The best part is that if we all agree on the above, the next 
> draft will be 1/3 of the size -- easier read for you. :)
> 
> Thanks,
> Anton. 
>     
> 
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
> 
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec