Subject: RE: [Syslog] plain tcp syslog

From: Marshall Glen <[email-masked]>
Date: Tue, 18 Oct 2005 10:34:25 -0400

RFC 3881 is transport agnostic.  However, DICOM Supplement 99 and the IHE
technical framework that specify its implementations currently require
Reliable Syslog COOKED.  The issue is the maximum supported length.  RFC
3195 does not specify a limit.  So the issue is what that limit should be.

Many of the medical devices that implement an audit capability are not
general-purpose computers, e.g., radiological modalities.  A simple protocol
stack like BEEP is preferable, for a variety of good reasons, for those
cases.

Glen Marshall  
 
-----Original Message-----
From: Darren Reed [mailto:[email-masked]]
Sent: Tuesday, October 18, 2005 10:23 AM
To: Marshall Glen
Cc: [email-masked]; 'Rainer Gerhards'; [email-masked]
Subject: Re: [Syslog] plain tcp syslog

> 
> I'd like to see that too, although I think the length needs to be 32K for
> healthcare audit records (see RFC 3881).

Why ?

RFC 3881 doesn't specify that syslog needs to be anywhere.

If you've got long records that need to be saved for audit purposes
then perhaps a protocol other than syslog should be used for this ?

Just because you have a hammer doesn't make everything you want to
fix a nail. (or however it goes :)

Darren

-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions 
USA, Inc. and are intended only for the addressee(s).  
The information contained herein may include trade secrets or privileged or 
otherwise confidential information.  Unauthorized review, forwarding, printing, 
copying, distributing, or using such information is strictly prohibited and may 
be unlawful.  If you received this message in error, or have reason to believe 
you are not authorized to receive it, please promptly delete this message and 
notify the sender by e-mail with a copy to [email-masked] 

Thank you

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Darren Reed <[email-masked]>
Date: Wed, 19 Oct 2005 00:55:38 +1000 (EST)

> 3195 does not specify a limit.  So the issue is what that limit should be.

Well whoever wrote DICOM Supplement 99 and the IHE technical
framework should be told they screwed up in deciding that this
was the way to go and implementors should use something else
that makes sense.

> stack like BEEP is preferable, for a variety of good reasons, for those

BEEP is NOT simple.
BEEP is extraordinarily complex solution for what is a very simple
problem.

If it was simple syslog over TCP, today, would use it.

In open source, people vote with their feet (or their code) and the
result of that poll is that BEEP for syslog over TCP is a failure.

BEEP and syslog is like an orphan looking for someone or something
to make it feel loved.

Darren

---

From: [email-masked]
Date: Tue, 18 Oct 2005 13:06:43 -0400 (EDT)

> was the way to go and implementors should use something else

Look in a (virtual) mirror.  Supplement 99 was issued for public comment
before RFC 3195 was approved, and we did inform the syslog group, and
there was no comment.  But, at the time the syslog group was still
pushing the used of BEEP through the approval process in the IETF and
I'm not surprised that they thought that DICOM's use of BEEP was
appropriate.  They were still pushing BEEP themselves.  DICOM was just
trying to avoid re-inventing the wheel and following their lead.

In fact, Supplement 99 is still in frozen draft for trial implementation
stage.  We recognized the novelty and uncertainty in all this.  So it is
not yet issued as part of the standard.  It is gathering public
feedback.  Yours is appreciated.

The issue of message size is very important in healthcare.  For other
reasons we must use XML encoding.  This has the practical impact of
increasing message size by a factor of 5-10.  So a message that sensible
people would put into 2-3KB expands to 20+KB when XML encoded.  That's
life.  We have to deal with big messages.  

> If it was simple syslog over TCP, today, would use it.

Unfortunately TCP alone is not going to address the reliability concern.
On that front we are looking for a reliable application level datagram
service. 

The problem scenario for TCP is primarily driven by mobile equipment,
although some kinds of network problems and equipment problems can
trigger it.  It's the mobile equipment that worries me.  The others are
low enough probability that I don't worry.

On all of the interesting OS systems, the TCP stack will return
"success" for transmission of a small message (where small means it fits
in the unused portion of a TCP window).  The message need not have left
the system yet.  In fact, the network may be down or disconnected.  The
OS still returns "success", so the application thinks that the message
has been sent, takes it off the queue, proceeds to the next message,
etc. If the problem is something like a loose cable or router glitch,
the messages flow through and get delivered when the problem is fixed.

But, if the sending machine is power cycled, applications restarted, or
even just attached to a different network, all the messages in that
buffer are lost.  This is highly likely in the case of mobile equipment,
and this kind of failure would be commonplace.  It is  not practical to
expect people to follow a rigid procedure before unplugging mobile
equipment from the network.

The solution (used by DICOM, BEEP, HL7, etc.) is to demand an
application level ACK before considering the message delivered.

Any simple datagram framing on top of TCP delivers that.  BEEP is
overkill for what we need.  but at the time BEEP was what the syslog
group was using.  Maybe I should propose a simple protocol like DICOM
:-). (It really is a very simple protocol to implement.  And there are
about 20 open source implementations already. It's much simpler to
implement than a web server.)

A reliable datagram service needs:
 1) Datagram framing (start/stop).
 2) Datagram identification, e.g. sequence number.
 3) Datagram acknowledgement/reject/retransmit.
 4) Asynchronous operation (for reasonable performance)

You need the identification and asynchronous operation so that the
sender can stream datagrams out at full speed and keep the network
pipeline full.  We've seen too many problems in the DICOM world where
failure to support asynchronous operation leads to unanticipated
performance problems.  You need to deal with out of order
acknowledgement and recovery up front to avoid nasty compatibility
issues later.  So define asynchronous operation from the beginning.

As long as the underlying error rate is low a very simplistic ack/nak
system will work just fine.  TCP and TLS deliver that low error rate.  

I would be happy with a reliable datagram framing service that could
then be planted on top of UDP, TCP, or TLS.  That lets me make the rest
of the implementation tradeoffs separately. I can use TLS when I need
authentication or encryption. I can use TCP when I'm traversing a
network where message size or network characteristics make UDP
unacceptable. I can use UDP when I have a suitable network environment.

The discussions so far have ignored the mobile environment. In the
mobile environment the use of TCP can lead to data loss with equipment
relocations. That would be a problem. 

R Horn