RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-transport-udp-02.txt

["Anton Okmianski" <aokmians@cisco.com>]

Rainer:

> Some points:
> 
> - you use "domain.com" in some examples. I recommend changing 
> this to "example.com", which has been reserved for this use.

Yes, will change.  You already commented on this, and I just lost
track of this issue.  Sorry about it.  

> - In 3.4, the draft says:
> 
> ######
>    All implementations MUST support sending and receiving syslog
>    messages up to and including the size which does not require
>    fragmentation (507 bytes for IPv4 and 1191 bytes for IPv6).  This
>    size excludes the overhead of the syslog transport and UDP/IP
>    headers.  Support for larger messages is encouraged.
Implementors
>    SHOULD clearly state the maximum supported message size in
>    documentation.
> ######
> 
> Actually, all implementations MUST support a message size of 
> 65,000 bytes, because this is the required minimum in 
> -protocol 4.1. We agreed on this minimum after long 
> discussions on the message size. I'd actually prefer not to 
> re-iterate this. But if we must, let me say that a guaranteed 
> message size of 507 bytes looks far too low to me.
> 
> Please note that the -protcol requirement meant that all 
> implementations MUST support fragmentation.
> 
> Sorry I didn't spot this in the -01 version...
> 
> I've also noticed that in -protocol, I have limited that max 
> message size to 16,000,000 bytes in -protocol. It might make 
> sense to sync this. I can go up with my number.

Indeed we discussed this at length, but my recollection of conclusions
was different. :)  Let's revisit.  We decided (I thought) that we
can't force transport implementors into supporting fragmentation as it
was too complicated. Plus, we can't them into supporting the maximum
message size as the common denominator may be too small. 

Hence, only the size that can be transported without fragmentation
must be supported by transport implementors.  However, a full
transport implementation will support fragmentation and size of up to
16777216 bytes.   

I think what we need is a statement in -protocol that it supports a
message size up to 16777216, but transports MAY impose a different
limit. 

It was mentioned that some devices will physically not be able to
handle large messages, where "large" can be quite a small number.
Restricting all messages to this common denominator is not good, so we
have a multi-tier support system. People are not likely to support
streaming of message parts in their implementations, so available
memory will be an issue.  

Administrators will choose the appropriate implementations. Should we
add a statement that transport implementations MUST document maximum
supported message size? 

I know it is less than optimal, but requiring all transports to
support some huge size is not a good idea either IMO. 

You also had an idea for doing fragmentation within the -protocol by
upper layer. I originally liked it.  But later people commented that
this was improper layering and shifted responsibilities of transport
layer up the stack.  I agree with this.  It would have introduced
potential fragmentation on several layers and we would have still
forced the higher layer to deal with UDP sizing constraints. 

I agree this issue deserves discussion. Let's have it and put it bed
for good. 

> I do not fully understand what you mean in 4.2 by:
> 
> #####
>  No concurrent port reuse on the same host is
>    allowed.
> #####
> 
> It's probably just my English, but I do not get it. I'd 
> appreciate if you could elaborate a little.

What this refers to is the use of SO_REUSEPORT socket option which
allows multiple sockets to be bound to the same port.  I guess it
would not be a problem if the two different consumers of the socket
(maybe threads) use different MessageId numbers.  And this is stated
as requirement elsewhere: all message parts must be send using the
same MessageId and source port among other things.   

Following your suggestion, we already allow multiple different ports
to be used concurrent within a single process, so I have no problem
with removing this restriction. It is too implementation-specific
anyway.  What do you think?

Thanks,
Anton. 

_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec