Review of draft-ietf-syslog-transport-udp-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've reviewed this document as part of the transport directorate's
ongoing effort to review key IETF documents. These comments were
written primarily for the transport area directors. Document
editors and WG chairs should treat these comments just like any other
last call comments. Feel free to forward to any appropriate forum.

Summary:  This document could go into more detail with respect
to transport behavior.  In places the wording could be improved. 

Section 1

"The IPv4 version of
this transport mapping is REQUIRED for all syslog protocol
implementations on devices supporting IPv4.  The IPv6 version of this
transport mapping is REQUIRED for all syslog protocol implementations
on IPv6-only devices."

So we are saying that a syslog implementation on a dual-stack host
isn't even recommended to support IPv6?  This would imply that a
dual-stack implementation may not be able to send syslog messages
if it has IPv6 connectivity, but not IPv4.  This doesn't make sense
to me. 

Section 3.2

"  IPv4 syslog receivers MUST be able to receive datagrams with message
   size up to and including 480 octets.  IPv6 syslog receivers MUST be
   able to receive datagrams with message size up to and including 1180
   octets.  All syslog receivers SHOULD be able to receive datagrams
   with messages size of at least 2048 octets."

If I read this literally, it seems to imply that IPv4 receivers must
be able to receive datagrams with a message size of 0 to 480 octets,
and should be able to receive messages greater than 2048 octets, and 
IPv6 receivers must be able to receive datagrams with a message size 
of 0 to 1180 octets, and should be able to receive messages greater 
than 2048 octets.  What about IPv4 messages from 480 to 2047 octets, or
IPv6 messages from 1181 to 2047 octets?  Are we saying that reception
of these messages sizes is optional??

"  The above restrictions and recommendations establish a baseline for
   interoperability.  The minimum required message size support was
   determined based on the minimum MTU size that internet hosts are
   required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6
   [4].  Datagrams that fall within these limits have the greatest
   chance of being delivered because they do not require fragmentation."

One could interpret this to mean that datagrams between 576 and 1280
octets have the greatest chance of delivery, which isn't what you 
mean.  You might say "Datagrams that conform to these limits..."

"   When network MTU is not known in advance and cannot be reliably
   determined using path MTU discovery [7], the safest assumption 
   is to restrict messages to 480 octets for IPv4 and 1180 octets 
   for IPv6."

There are issues with syslog usage of classical path MTU 
discovery, since ICMP Packet Too Big messages may not be 
delivered or processed for some reason.  Since syslog 
doesn't support acknowledgement, it can't determine when
packets are lost, making it difficult to implement alternatives
such as draft-ietf-pmtud-method.  You might talk a bit more 
about these implications. 

Section 4

   "This section
   discusses reliability issues inherent in UDP that implementers and
   users MUST be aware of."

What implementation obligations does the MUST imply?  I'm unclear what
an implementer is supposed to do. 

Section 4.1

"   In some circumstances the sender can receive an ICMP error message or
   other indication of a transmission problem.  If the sender receives a
   reasonable indication that a datagram has been lost, it MAY
   retransmit the datagram."

This paragraph seems too vague.  Are we suggesting that the implementer
may retransmit in response to any ICMP error message?  Also, are there
any recommendations with respect to retransmission timers or failover
behavior? 

Section 4.2

   "However, checksums do not
   guarantee corruption detection, and this transport mapping does not
   provide for message retransmission when a corrupt message is
   detected."

It might be clearer to say that there is no acknowledgement mechanism,
given the potential for retransmission described in Section 4.1. 

"  A special case of corruption is corruption introduced by the UDP
   implementation itself.  For example, several earlier UDP
   implementations defaulted to a buffer size of less than 65535 octets
   and truncated larger payloads upon receipt [8].  By following the
   message size recommendations specified in this document, application
   developers can significantly reduce the risk of this type of error."

This probably would better fit in Section 3.2.

Section 4.3

"   The UDP does not provide for congestion control.  Any network host or
   router can discard UDP packets when it is overloaded, and can
   optionally provide an ICMP error to indicate this."

Are you referring to "Source Quench" here?  I think you need to talk about
syslog's response to potential congestion indications in more detail. 
Section 4.1 raises the possibility of retransmission, which without
backoff doesn't seem like a great idea in situations where congestion
is being experienced. 

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]