On 19 Oct, Darren Reed wrote: >> >> 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. > > 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. >
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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
