Document: draft-ietf-tsvwg-udp-guidelines-03
Reviewer: Audet, Francois 
Review Date:  10/12/2007
Review Due: 10/15/2007
Review Type: Cross-Area


Summary: 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"