[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] UDP message size issue proposal
Rainer:
Glad you liked the latest proposal. I received two other votes for it
as well (from Andrew Ross and John Moehrke) and no disagreements.
So, I will go ahead with the proposal.
I will remove version field from udp transport as well. I agree that
in the unlikely scenario that we would need a new version of UDP
transport, we can add the version field at the very front which does
not conflict with syslog-protocol headers.
One clarification question on suggested text below.
> ####
> 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.
> ####
You really meant: "Each transport mapping MUST support a *minimum*
size of 480 octets or more."
Or actually, this should probably be:
"Each transport mapping MUST support transmission of messages of at
least 480 octets".
Note, we are not placing a requirement on sender or receiver here.
Just saying that transport protocol must be able to handle messages of
this size. Right?
Anton.
>
> 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