I need to correct myself slightly... (below)

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Rainer Gerhards
> Sent: Thursday, June 05, 2008 3:49 PM
> To: [EMAIL PROTECTED]
> Cc: syslog
> Subject: Re: [Syslog] Subject Name verification policy
> 
> Robert,
> 
> I am fine with your text.
> 
> <slightlyOffTopic>
> The reliability issue is not rooted in disasters or other uncommon
> scenarios. As of my testing, confirmed this month by Martin, the
> probability of message loss even in a simple server restart case is
> very
> high. For a busy network, I'd say it tends toward 100%, though I
cannot
> provide hard evidence - I didn't bother to do a statistically large
> enough sample to back that statement. After all, it is irrelevant if
> there is a 80% or 100% probability - the point is that it is very high
> (probability of message loss increases with traffic volume).

This was the number for (non-standard) plain TCP syslog (still widely
deployed). With -transport-tls, it looks a bit better, because we have
the TLS closure process. But there are still issues. Just to clarify.

> In any case, I expect that an operator of an enterprise logging system
> will routinely see message loss (if he cares to detect it) inside a
> system using -transport-tls. Of course -transport-udp will be much
> worse. But the point is that an auditor may very well question the
> completeness of the log data under *normal* circumstances. Martin has
> found a trick to get some better reliability for these normal
> circumstances, but the trick only works in a fast, lossless network
> with
> low traffic volume and without bursts. Plus, it is racy. But it is the
> best you can do.
> </slightlyOffTopic>
> 
> All of this off-topic should NOT go into the document, but it is the
> reasoning behind my proposal.
> 
> Rainer
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 05, 2008 3:23 PM
> > To: Rainer Gerhards
> > Cc: Joseph Salowey (jsalowey); syslog; [EMAIL PROTECTED]
> > Subject: RE: [Syslog] Subject Name verification policy
> >
> > "Rainer Gerhards" <[EMAIL PROTECTED]> wrote on 06/05/2008
> > 08:01:37
> > AM:
> >
> > > I think I should have been more clear. I meant a note along these
> > lines
> > > (and only these lines, without any more specifics).
> > >
> > > ###
> > > It should be noted that this transport does not use
> application-level
> > > acknowledgments. As such, there exists situations where loss of
> data
> > > may occur. This protocol is not suitable if a 100% reliable
> solution
> > > is desired.
> > > ###
> > >
> >
> > How about just
> > ###
> > It should be noted that this transport does not use
application-level
> > acknowledgments. As such, there exists situations where loss of data
> > may occur.
> > ###
> >
> > Maybe someone will find or write a good reference article explaining
> > the
> > application level issues with TCP/IPv4, TCP/IPv6, etc.  Then an in
> > depth
> > explanation could be given once for all the many applications that
> > care.
> > People who are serious about this will need the full details.  The
> rest
> > deserve just the short warning.  I don't want them blindly telling
> > everyone that the syslog group has officially said that they
> shouldn't
> > use
> > syslog-tls because it isn't reliable.  That is what would happen if
> we
> > include that final sentence.
> >
> > There are unsophisticated users who routinely demand 100%
> reliability.
> > I
> > deal with them by asking about how they plan to handle power
> failures,
> > hurricanes, earthquakes, floods, tornados, etc.  I know that when I
> > cared
> > about such stuff I could quote the local power grid reliability
> > statistics
> > off the top of my head, and could explain our decision tree on the
> size
> > of
> > the fuel tank for the auxiliary diesel generator.  I was also on top
> of
> > disk drive reliability figures.  This was before RAIDs and hot swap
> was
> > very expensive.  It turned out that downtime for disk drive problems
> > was a
> > major issue as you went below 10min/year of downtime.  Their
response
> > to
> > the basic disaster questions establishes what kind of response to
> give
> > for
> > applications level data loss.
> >
> > R Horn
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog

Reply via email to