Re: [tsvwg] Review of draft-ietf-tsvwg-rfc5405bis-02.txt

["Eggert, Lars" <[e-mail]>]

Hi,

sorry it took me so long to get back to this.

On 2015-4-23, at 14:31, Magnus Westerlund <[e-mail]> wrote:
> 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.

That is what the text in the same paragraph before the lines you quoted is about. Maybe we could be clearer that the guideline above is for transmission over the wider Internet?

> 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.

Right, but is 5.6Mbps an issue on a LAN? Remember that if there is loss, the calculated RTT will increase, and the rate therefore decrease. When there is no loss and the RTT is 2ms, obviously the LAN can sustain that traffic. (TFTP is basically operating in this way, and doesn't seem to create huge issues on 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.

Right. There is some text in the beginning of 3.1 that tries to say so:

   It is important to stress that an
   application SHOULD perform congestion control over all UDP traffic it
   sends to a destination, independently from how it generates this
   traffic.  For example, an application that forks multiple worker
   processes or otherwise uses multiple sockets to generate UDP
   datagrams SHOULD perform congestion control over the aggregate
   traffic.

Maybe that's not clear enough?

> 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.

Fair point. Should we then introduce some limit on pps that is considered "low data rate" and for everything above that say "use CC"? What limit should we pick?

> 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.

Done, thanks.

> 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.

Same answer :-) Should we maybe point to the text in 3.1 or repeat it here?

> 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.

CRC is given as an example. I'm adding "e.g., through a Cyclic Redundancy Check (CRC) or keyed or non-keyed cryptographic hash included with the data to verify the integrity of an entire object/file sent over the UDP service."

> 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?

Done.

> 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.

Done.

> 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.

Changed.

Thanks!

Lars