> I definitely agree that the verification mechanism should have as
> little impact on performance as possible. It might be useful to
> mention some possible mechanisms for accomplishing this (either here
> or in the "Resource Utilization Considerations" section), such as an
> ACK window size determined in the handshaking phase.
I disagree. This is a requirements document.
Implementation considerations of this level
belong in a different document.
> I'm not sure what you mean by saying that the verifyable delivery
> mechanism doesn't need to be "perfectly accurate". It seems to me
> that if it's not accurate, it doesn't do any good.
Proper guarantee of exactly one copy of
every message is very difficult and expensive
(two phase commit with roll-back and that
sort of stuff). It's also not necessary for system
logs, IMO.
Instead, we can do negative verification
where the syslog daemon on the source machine
keeps track of whether a message has been
acknowledged or not. The daemon itself
can implement a timeout to do retransmisions,
transmission to a failover logging server, etc.
At the application level, the application can
decide whether to synchronously wait/block for
each acknowledgement, can implement its
own timers, etc., etc.
I guess I should expand on this a bit more in the document.
> This is an excellent point. You might want to expand upon that to
> describe both a "multiple primary" setup (where messages are always
> sent to multiple servers for redundancy) and a "failover" setup (where
> a secondary log server is used when the primary is unavailable).
Yeah, that's worth mentioning. Thanks.
> > 3. Logging protocols should not require log
> > senders to wait synchronously for positive
> > acknowledgement of messages sent.
> > Therefore making denial of service attacks
> > on log senders more difficult through the
> > generation of excessive traffic on a
> > particular network link.
>
> This doesn't address the issue of initial message submission, where
> the process submitting the message needs an ACK for each message if it
> wants to use verifyable delivery. It might be better to say that the
> client and server will determine during handshaking whether or not
> an ACK should be sent after each message (i.e., set the ACK window
> size to 1).
The problem is that an ACK window size
of 1 is a real performance killer, and you don't
want your service to shut down just because
messages are getting generated just a little bit
faster during peaks than your log server can
handle them when it's still much slower on average.
Also, only a very few messages sent by a very
few applications have the TSEC requirement
to cause a server shutdown, so you definitely
don't want to set the entire stream to require
instant ACKing.
Instead, I think the mechanism I described above
is the best. This way, applications can block
if they want to, but the overall stream keeps moving.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
