UDP Usage Guidelines
draft-ietf-tsvwg-rfc5405bis-19

[Ballot comment]
Before starting to read this document, a first reaction: let me stress that this type of document should really benefit from a "changes since RFC5405" section.

I see in the abstract:

  This document obsoletes RFC5405 and adds guidelines for multicast UDP
  usage.


I see in the intro section:

  [RFC5405] was scoped to provide guidelines for unicast applications
  only, whereas this document also provides guidelines for UDP flows
  that use IP anycast, multicast, broadcast, and applications that use
  UDP tunnels to support IP flows.

Looking at the diffs, there is certainly more than this
https://www.ietf.org/rfcdiff/rfcdiff.pyht
=> https://tools.ietf.org/rfc/rfc5405.txt
=> https://tools.ietf.org/id/draft-ietf-tsvwg-rfc5405bis-18.txt

Background:
https://datatracker.ietf.org/doc/draft-wilde-updating-rfcs/ and the related discussion on having a "changes since RFCxxxx", even for obsolete.

=================================
Now the review.

Like Stephen, I was wondering about the QUIC involvement and awareness.

- TCP-Friendly Rate Control (TFRC) on the first occurence
- Section 3.1.1 might refer to active probing in IPPM, RFC 7679
- Section 3.1.5: Question: instead of implementing a congestion control scheme, is this valid to limit the UDP traffic to a certain value, such as a fraction of the outgoing link bandwidth? At least, that should be true for the section 3.6 "controlled environment"

[Ballot comment]
Well written doc! Thanks! One comment, not really an issue, just want to mention it:
Recommendations on "Limited Applicability and Controlled Environments" seem slightly redundant (in section 3.6 but also two times earlier in the doc). Maybe it would be helpful to at least have the definition of 'General Internet' and 'Controlled Enviroment' (currently in section 3.6) earlier in the doc...?

[Ballot comment]
Well written doc! Thanks! One comment, not really an issue, just want to mention it:
Recommendation on "Limited Applicability and Controlled Environments" seem slightly redundant (in section 3.6 but also two times earlier in the doc). Maybe it would be helpful to at least have the definition of 'General Internet' and 'Controlled Enviroment' (currently in section 3.6) earlier in the doc...?

[Ballot comment]
Hi, thanks for this document.  I just have a few nit level comments:

- I agree with Benoit that a more detailed "changes since 5405" section would be helpful (separate from the inter-version change section.)

- IDNits points out that RFC  896 is obsoleted RFC 7805. Is the reference to 896 intentional? (The shepherd writeup mentions a different obsolete reference, but not this one.)

- 3, 2nd paragraph:
Is it reasonable to avoid the negation in "not rare" and just say "common"?

-3.1.1, 3rd paragraph: Please expand TFRC on first mention. (I think the original 5405 text that expanded it got moved to later in the document.)

-3.4, paragraph 3: "An application MAY optionally discard UDP datagrams
  with a zero checksum [RFC1122]"
Does this MAY give permission to discard, or state the fact that 1122 gives permission to discard? (If the second, please consider non-2119 language to avoid the ambiguity.)

-3.4.1, last bullet in list: I think there may be an editing or copy/paste error here.  (Limit the usage of what? Is that section 3.6 _of_ RFC7510?)

-3.6: Yay!

- section 6, third paragraph: "Applications MAY also want to offer ways to limit the
  number of requests they respond to in a time interval, in order to
  cap the bandwidth they consume."

Is that MAY intentionally capitalized? Seems like a statement of fact.

-section 6, paragraph 5:  I concur with Kathleen's comment to reference 7525 in the DTLS discussion.

[Ballot discuss]
= Section 3.17 =

"An application sending ECN-capable datagrams MUST provide an
      appropriate congestion reaction when it receives feedback
      indicating that congestion has been experienced.  This must result
      in reduction of the sending rate by the UDP congestion control
      method (see Section 3.1) that is not less than the reaction of TCP
      under equivalent conditions."
   
Is the second "must" meant to be normative? If so, this worries me a bit. RFC 6679 I believe retains flexibility for endpoints to react to congestion in ways that are different from TCP and dependent on specific codecs, topologies, and other factors. RFC 3551 provides a lot of qualification in the requirements it places around equivalence to TCP's behavior. So I would be concerned about how this requirement, if normative, would affect RTP and other protocols.

If it's not meant to be normative, I would suggest using "ought to" or some other word.

[Ballot comment]

Thanks for updating this. I have one real question to
ask, and a few nitty things...

Some of the text in section 6 seems outdated, e.g. I'm
not sure we'd recommend GSS-API or AH these days. I
wonder would that section be worth running by the saag
list to see if anyone has time and interest to offer
better text? (I would be happy to try write such text
myself but other than the bit below, don't have time
right now, sorry.)

Note that my review is based on the diff from 5405 [1]

- General: I wondered if the folks interested in QUIC
have been involved with this? I assume they have and that
this update won't cause issues with the just-formed QUIC
WG. (If we did expect such issues, then we probably ought
be explicit about that and I didn't see any mention of
QUIC in this document.)

- 3.1.1: "Latency samples MUST NOT be derived from
ambiguous transactions" - I don't understand how that
MUST NOT can be universally applied, maybe that's just a
use of 2119 terms for emphasis?

- 3.1.2: I wondered if there's anything useful to say
about LPWAN applications that may meet the "don't send
much" criterion, but I assume it's too early to say most
likely.

- (some text that moved, which I why I noticed it:-)
section 6 says: "Applications that respond to short
requests with potentially large responses are vulnerable
to amplification attacks, and SHOULD authenticate the
sender before responding. The source IP address of a
request is not a useful authenticator, because it can
easily be spoofed. Applications MAY also want to offer
ways to limit the number of requests they respond to in a
time interval, in order to cap the bandwidth they
consume."

I think that's a bit wrong and a bit out of date. I'd
suggest instead maybe something more like:

"Applications that respond to short requests with
potentially large responses are a potential vector for
amplification attacks, and SHOULD take steps to minimize
their potential for being abused as part of a DoS attack.
That could mean authenticating the sender before
responding noting that the source IP address of a request
is not a useful authenticator, because it can easily be
spoofed. Or it may mean otherwise limiting the cases
where short unauthenticated requests produce large
responses. Applications MAY also want to offer ways to
limit the number of requests they respond to in a time
interval, in order to cap the bandwidth they consume."

[1] https://tools.ietf.org/rfcdiff?url1=rfc5405&url2=draft-ietf-tsvwg-rfc5405bis-18.txt

[Ballot comment]
Before starting to read this document, a first reaction: let me stress that this type of document should really benefit from a "changes since RFC5405" section.

I see in the abstract:

  This document obsoletes RFC5405 and adds guidelines for multicast UDP
  usage.


I see in the intro section:

  [RFC5405] was scoped to provide guidelines for unicast applications
  only, whereas this document also provides guidelines for UDP flows
  that use IP anycast, multicast, broadcast, and applications that use
  UDP tunnels to support IP flows.

Looking at the diffs, there is certainly more than this
https://www.ietf.org/rfcdiff/rfcdiff.pyht
=> https://tools.ietf.org/rfc/rfc5405.txt
=> https://tools.ietf.org/id/draft-ietf-tsvwg-rfc5405bis-18.txt

Background:
https://datatracker.ietf.org/doc/draft-wilde-updating-rfcs/ and the related discussion on having a "changes since RFCxxxx", even for obsolete.

[Ballot comment]
Before starting to read this document, a first reaction.
Let me stress that this type of document should really benefit from a "changes since RFC5405" section.
I see in the abstract:

  This document obsoletes RFC5405 and adds guidelines for multicast UDP
  usage.


I see in the intro section:

  [RFC5405] was scoped to provide guidelines for unicast applications
  only, whereas this document also provides guidelines for UDP flows
  that use IP anycast, multicast, broadcast, and applications that use
  UDP tunnels to support IP flows.

Looking at the diffs, there is certainly more than this
https://www.ietf.org/rfcdiff/rfcdiff.pyht
=> https://tools.ietf.org/rfc/rfc5405.txt
=> https://tools.ietf.org/id/draft-ietf-tsvwg-rfc5405bis-18.txt

Background:
https://datatracker.ietf.org/doc/draft-wilde-updating-rfcs/ and the related discussion on having a "changes since RFCxxxx", even for obsolete.

[Ballot comment]
Thank you for a very well-written draft!  When DTLS is discussed in the security considerations section, could you include a pointer to the best practices: https://tools.ietf.org/html/rfc7525

Thank you for also for addressing the SecDir review:
https://mailarchive.ietf.org/arch/msg/secdir/fOv00Tugy6CjPOuoReu2jHKS38k

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-rfc5405bis-13.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "David L. Black" , tsvwg@ietf.org, david.black@emc.com, draft-ietf-tsvwg-rfc5405bis@ietf.org, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (UDP Usage Guidelines) to Best Current Practice


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'UDP Usage Guidelines'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The User Datagram Protocol (UDP) provides a minimal message-passing
  transport that has no inherent congestion control mechanisms.  This
  document provides guidelines on the use of UDP for the designers of
  applications, tunnels and other protocols that use UDP.  Congestion
  control guidelines are a primary focus, but the document also
  provides guidance on other topics, including message sizes,
  reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
  and ports.

  Because congestion control is critical to the stable operation of the
  Internet, applications and other protocols that choose to use UDP as
  an Internet transport must employ mechanisms to prevent congestion
  collapse and to establish some degree of fairness with concurrent
  traffic.  They may also need to implement additional mechanisms,
  depending on how they use UDP.

  Some guidance is also applicable to the design of other protocols
  (e.g., protocols layered directly on IP or via IP-based tunnels),
  especially when these protocols do not themselves provide congestion
  control.

  This document obsoletes RFC5405 and adds guidelines for multicast UDP
  usage.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Document shepherd write-up:

                          UDP Usage Guidelines
                    draft-ietf-tsvwg-rfc5405bis-10

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


  The User Datagram Protocol (UDP) provides a minimal message-passing
  transport that has no inherent congestion control mechanisms.  This
  document provides guidelines on the use of UDP for the designers of
  applications, tunnels and other protocols that use UDP.  Congestion
  control guidelines are a primary focus, but the document also
  provides guidance on other topics, including message sizes,
  reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
  and ports.

The WG has requested Best Current Practice status because this draft
specifies general guidelines for use of UDP in any protocol (in many
cases, these guidelines are based on experience with UDP usage), and
because it is a replacement for (both obsoleting and expanding)
RFC 5405, which is a BCP (BCP 145).

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in UDP and congestion control.  The
draft has received significant review and critique from a number of
WG members and has undergone significant modification as a result.  A
significant area of expansion over RFC 5405 is the addition of multicast
guidelines; this UDP multicast guideline work began in a separate draft
that was merged into this draft by the WG so that protocol designers
would have one place to look for UDP guidelines.

Recent discussion in the WG has focused on issues related to the
increasing use of UDP to encapsulate other protocols; an important
outcome is the addition of Section 3.6 on Limited Applicability
and Controlled Environments where aspects such as equipment robustness
and operator traffic management may substitute for protocol features
(e.g., checksums, congestion management) that are necessary in
unrestricted environments such as the Internet in general.  This
draft incorporates guidelines based on lessons learned from
MPLS/UDP (RFC 7510), GRE/UDP (recent TSVWG WG Last Call) and the
routing area encapsulation design team's work (much broader draft
in the RTGWG WG).

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits 2.13.02 found an Internet-Draft that has been updated and a
reference to an obsolete RFC:

  -- Obsolete informational reference (is this intentional?): RFC 2309
    (Obsoleted by RFC 7567)

This reference is intentional, in part to indicate that congestion-
related concerns about UDP traffic have a long history.

There are no IANA Considerations.

Document shepherd write-up:

                          UDP Usage Guidelines
                    draft-ietf-tsvwg-rfc5405bis-10

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


  The User Datagram Protocol (UDP) provides a minimal message-passing
  transport that has no inherent congestion control mechanisms.  This
  document provides guidelines on the use of UDP for the designers of
  applications, tunnels and other protocols that use UDP.  Congestion
  control guidelines are a primary focus, but the document also
  provides guidance on other topics, including message sizes,
  reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
  and ports.

The WG has requested Best Current Practice status because this draft
specifies general guidelines for use of UDP in any protocol (in many
cases, these guidelines are based on experience with UDP usage), and
because it is a replacement for (both obsoleting and expanding)
RFC 5405, which is a BCP (BCP 145).

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in UDP and congestion control.  The
draft has received significant review and critique from a number of
WG members and has undergone significant modification as a result.  A
significant area of expansion over RFC 5405 is the addition of multicast
guidelines; this UDP multicast guideline work began in a separate draft
that was merged into this draft by the WG so that protocol designers
would have one place to look for UDP guidelines.

Recent discussion in the WG has focused on issues related to the
increasing use of UDP to encapsulate other protocols; an important
outcome is the addition of Section 3.6 on Limited Applicability
and Controlled Environments where aspects such as equipment robustness
and operator traffic management may subsitute for protocol features
(e.g., checksums, congestion managment) that are necessary in
unrestricted environments such as the Internet in general.  This
draft incorporates guidelines based on lessons learned from
MPLS/UDP (RFC 7510), GRE/UDP (recent TSVWG WG Last Call) and the
routing area encapsulation design team's work (much broader draft
in the RTGWG WG).

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits 2.13.02 found an Internet-Draft that has been updated and a
reference to an obsolete RFC:

  -- Obsolete informational reference (is this intentional?): RFC 2309
    (Obsoleted by RFC 7567)

This reference is intentional, in part to indicate that congestion-
related concers about UDP traffic have a long history.

There are no IANA Considerations.