Subject: [Tsvwg] RE: Request to review UDP guidelines document from TSVWG

From: "Francois Audet" <[email-masked]>
Date: Fri, 12 Oct 2007 15:38:04 -0500

I found the document to be clear and readable, and that it provides good
advice.
I have no major comment on it.

Often people decide to use UDP as a transport for a protocol because
they
do not recognize that their particular protocol or application may
suffer from congestion
control problems, or exceed the path MTU. Or they may erroneously
believe
that its easier to build their own reliability mechanism on top UPD
instead
of using a transport that has it built in. Or they believe that the
performance
difference will be big. Or they don't think they'll need to worry about
NAT traversal.
In other words, people fail to recognize these problems. SIP is a
perfect example
of a protocol than can run over UDP that had a problem with almost all
the points made
in the document.

Some comments:

- Section 3.1.2. The section describes that SIP uses a initial value for
UDP of 500ms instead
  of the recommended 3s. Is this good or bad? I'm having some difficulty
understanding what
  the point is.

- Section 3.3: change last sentence of 3.3 to "Applications that do
require a reliable message
  delivery SHOULD choose a transport protocol that provides it, or, if
not possible, implement 
  an appropriate mechanism themselves."

- Section 3.4. The phrase "It also verifies that the packet was
delivered to the intended 
  destination" is not really accurate, as it's only the receiver that
can verify this, not
  the sender. Maybe change it to something like "It also allows the
receiver to verify that 
  it was the intended destination of the packet".

- Section 3.5: You might want to mention that some middleboxes block UDP
altogether. Another
  type of middlebox you might want to mention are load balancers. I also
believe these types of
  devices typically operate better with TCP than UDP. It might be
worthwile mentioning that
  "Client-server" type traffic (where the server side is on the
reachable side of the middlebox)
  is easier to support with TCP than with UDP: for example, "signalling"
traffic such as SIP.

- Section 4. This section seems focused more on what security mechanisms
are suitable for
  UDP. It should probably also briefly discuss the secruity implications
of using UDP instead
  of a congestion-controlled transport protocol such as TCP or SCTP (if
any?).

- Section 5. I'm not sure I see the benefit of this section, at least in
its current form. Without
  the proper context, it is pretty difficult to read. I think we should
remove the section entirely.

Editorial Comments:

- Section 3, second paragraph, las line of p.4: change "its different"
to "their different"