Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc5405bis-02.txt

From: [email-masked]
Date: Wed, 08 Apr 2015 05:25:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : UDP Usage Guidelines
        Authors         : Lars Eggert
                          Godred Fairhurst
                          Greg Shepherd
	Filename        : draft-ietf-tsvwg-rfc5405bis-02.txt
	Pages           : 42
	Date            : 2015-04-08

Abstract:
   The User Datagram Protocol (UDP) provides a minimal message-passing
   transport that has no inherent congestion control mechanisms.
   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.

   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.

   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.

   If published as an RFC, this document will obsolete RFC5405.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc5405bis-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Apr 2015 14:31:42 +0200

Hi,

I have reviewed and have some comments:

1. Section 3.1.1:

    Applications that support an uncontrolled or unadaptive transmission
    behavior SHOULD NOT do so by default and SHOULD instead require users
    to explicitly enable this mode of operation.

I think on could add as an alternative to be integrated with resource 
reservation system so that this mode is only engaged after having been 
granted the resources.

2. Section 3.1.2:

    Applications that at any time exchange only a few UDP datagrams with
    a destination SHOULD still control their transmission behavior by not
    sending on average more than one UDP datagram per round-trip time
    (RTT) to a destination.

In the discussions around the RTP circuit breakers we have found that 
this basic rule has a quite significant corner case that we need to 
discuss. As RTT -> 0, the allowed rate goes to infinity. Now RTT will 
not go to infinity, but I think we have an potential issue already on a 
LAN. Assuming a RTT of 2 ms, you are allowed to send 500 packets a 
second. Just by a 1400 bytes MSS, that is 5.6 mbps. If you have a lan 
supporting 9k Ethernet payload, then your supported non-congestion 
controlled rate becomes 36 mbps. A number of instances of an application 
behaving like this will clearly cause issues in quite a lot of LANs.

So the issue is really that any application that send sufficient number 
of packets per seconds also needs to be congestion controlled, even if 
they are of a one packet per RTT type. This should be clarified, and 
possibly some guidance on what to frequent really is. An application 
sending 10 packets per seconds to a destination, even if only one per 
RTT clearly can sample the path well enough to have a proper CC.

3. Section 3.1.3:

    Even low data-volume UDP flows may benefit from rate control, e.g.,
    an application that sends three copies of a packet to improve
    robustness to loss is RECOMMENDED to pace out those three packets
    over several RTTs, to reduce the probability that all three packets
    will be lost due to the same congestion event.

I would suggest that one changes "rate control" in the first line of the 
above paragraph to "packet pacing" as that is what being discussed. 
Usage of rate control is to easily misinterpreted to mean not the packet 
rate, but also the total bit-rate.

4. Section 3.1.5:

    Applications that support an
    uncontrolled or unadaptive transmission behavior SHOULD NOT do so by
    default and SHOULD instead require users to explicitly enable this
    mode of operation.

Same comment as in comment 1 above.

5. Section 3.4:

    Application developers SHOULD implement additional checks
    where data integrity is important, e.g., through a Cyclic Redundancy
    Check (CRC) included with the data to verify the integrity of an
    entire object/file sent over the UDP service.

I wonder if we should clarify this recommendation on additional checks. 
I think CRCs are good ways to verify that non-malicous changes has 
occured to the payload, but CRC may not be appropriate to "entire 
object/file" where better detection mechanisms may be needed that 
supports longer object better. Unless people would use a really long CRC 
polynom, I think keyed or non-keyed cryptographic hashes are more 
appropriate recommendation for object level changes, and if it can be 
keyed also protect against malicious changes.

6. Section 3.5:

     When an application is deployed in a
    controlled network environment, the deployer SHOULD investigate
    whether the target environment allows applications to use longer
    intervals, or whether it offers mechanisms to explicitly control
    middlebox state timeout durations, for example, using Middlebox
    Communications (MIDCOM) [RFC3303], Next Steps in Signaling (NSIS)
    [RFC5973], or Universal Plug and Play (UPnP) [UPnP].

Add Port Control Protocol to the list?

7. Section 4:

    The IETF has defined a reliable multicast framework [RFC3048] and
    several building blocks to aid the designers of multicast
    applications, such as [RFC3738] or [RFC4654].  Anycast senders must
    be aware that successive messages sent to the same anycast IP address
    may be delivered to different anycast nodes, i.e., arrive at
    different locations in the topology.

I think this paragraph needs to be split into two parts. As the first 
sentence and the Anycast one appears quite unrelated.

8. Section 6:

The IETF standard for securing RTP [RFC3550]
    communication sessions over UDP is the Secure Real-time Transport
    Protocol (SRTP) [RFC3711].

I think this sentence needs to be changed and primarily reference 
RFC7201. I would rather propose something like:

There exist a number of security options for RTP [RFC3550] over UDP, 
especially to accomplish key-management, see [RFC7201]. These options 
covers many different usages, including point-to-point, centralized 
group communication as well as multicast.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Matt Mathis <[email-masked]>
Date: Thu, 23 Apr 2015 21:59:26 -0700

On Thu, Apr 23, 2015 at 5:31 AM, Magnus Westerlund <
[email-masked]> wrote:

> In the discussions around the RTP circuit breakers we have found that this
> basic rule has a quite significant corner case that we need to discuss. As
> RTT -> 0, the allowed rate goes to infinity. Now RTT will not go to
> infinity, but I think we have an potential issue already on a LAN. Assuming
> a RTT of 2 ms, you are allowed to send 500 packets a second. Just by a 1400
> bytes MSS, that is 5.6 mbps. If you have a lan supporting 9k Ethernet
> payload, then your supported non-congestion controlled rate becomes 36
> mbps. A number of instances of an application behaving like this will
> clearly cause issues in quite a lot of LANs.
>

TCP itself has essentially the same corner case.  The above is more
conservative than standard TCP by no more than a factor of two, and that
factor of two has been in our approved code base forever  (from "if
(ssthresh <2) ssthresh=2;" )  I believe that a path having a 1uS RTT and a
bottleneck with a 1 packet drop-from-head queue will demonstrate TCP's
charming behavior (It does need to have early retransmit).

A simpler example would a 1uS path with a two packet drop tail queue.  It
is a slightly different, equally brutal, corner (cwnd=3, one loss every
other RTT or so, probably runs above 50% of link rate, even at 10Gb/s)

We need to kill the delusion that enforcing "TCP friendly congestion
control" is a solution to the Internet capacity allocation problem.   It is
neither necessary nor sufficient.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 29 Apr 2015 14:26:13 +0000

Thanks Magnus! I've put this on my change list, but it may take a while to spin a new version.

Lars

On 2015-4-23, at 14:31, Magnus Westerlund <[email-masked]> wrote:
> I think on could add as an alternative to be integrated with resource reservation system so that this mode is only engaged after having been granted the resources.
> 
> 2. Section 3.1.2:
> 
> In the discussions around the RTP circuit breakers we have found that this basic rule has a quite significant corner case that we need to discuss. As RTT -> 0, the allowed rate goes to infinity. Now RTT will not go to infinity, but I think we have an potential issue already on a LAN. Assuming a RTT of 2 ms, you are allowed to send 500 packets a second. Just by a 1400 bytes MSS, that is 5.6 mbps. If you have a lan supporting 9k Ethernet payload, then your supported non-congestion controlled rate becomes 36 mbps. A number of instances of an application behaving like this will clearly cause issues in quite a lot of LANs.
> 
> So the issue is really that any application that send sufficient number of packets per seconds also needs to be congestion controlled, even if they are of a one packet per RTT type. This should be clarified, and possibly some guidance on what to frequent really is. An application sending 10 packets per seconds to a destination, even if only one per RTT clearly can sample the path well enough to have a proper CC.
> 
> 3. Section 3.1.3:
> 
> I would suggest that one changes "rate control" in the first line of the above paragraph to "packet pacing" as that is what being discussed. Usage of rate control is to easily misinterpreted to mean not the packet rate, but also the total bit-rate.
> 
> 4. Section 3.1.5:
> 
> I wonder if we should clarify this recommendation on additional checks. I think CRCs are good ways to verify that non-malicous changes has occured to the payload, but CRC may not be appropriate to "entire object/file" where better detection mechanisms may be needed that supports longer object better. Unless people would use a really long CRC polynom, I think keyed or non-keyed cryptographic hashes are more appropriate recommendation for object level changes, and if it can be keyed also protect against malicious changes.
> 
> 6. Section 3.5:
> 
> I think this paragraph needs to be split into two parts. As the first sentence and the Anycast one appears quite unrelated.
> 
> 8. Section 6:
> 
> I think this sentence needs to be changed and primarily reference RFC7201. I would rather propose something like:
> 
> There exist a number of security options for RTP [RFC3550] over UDP, especially to accomplish key-management, see [RFC7201]. These options covers many different usages, including point-to-point, centralized group communication as well as multicast.
> 
> Cheers
> 
> Magnus Westerlund
>