Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rfc5405bis-06

["Black, David" <[e-mail]>]

<WG chair hat OFF>

Ok, I'm slightly late, but here are the rest of my comments on this draft.
I've tagged each as technical vs. editorial, and with my chair hat off, these
are open to discussion by the authors and anyone else interested (e.g., they
are not to be viewed as "MUST do this" WG chair comments)

Section 3, last paragraph: Technical

   If used correctly, these more fully-featured transport protocols are
   not as "heavyweight" as often claimed.

That responds to one frequent objection to use of congestion-controlled
IETF protocols.

Another objection that ought to be acknowledged is that
there is quite a bit of deployed Internet gear that doesn't support
transport protocols other than TCP or UDP.  For example, a frequent rationale
for use of UDP in encapsulations is that TCP's reliable delivery functionality
is not wanted and other protocols (e.g., DCCP) aren't supported by common
ECMP implementations at layer 2 and layer 3.

This "running code" objection should at least be acknowledged.  It
(unfortunately) also applies to discussion of UDP-Lite in 3.4.1, and
is noted at the end of that section.

End of 3.1.4: Editorial

   to reduce the probability that all three packets
   will be lost due to the same congestion event.

I suggest: "same congestion event." -> "same congestion (or other) event."

An example of an "other" event is a burst of radio interference on a
wireless link or network that is not compensated for by link measures
(e.g., link retransmission or link FEC).

3.1.5, p.11: Typos

	and ETC(0)/Not-ECT packets

ETC -> ECT
 ... and discipline the spelling corrector that was responsible ;-).

   [RFC6679] provides guidance an example of this support, by describing
   a method to allow ECN to be for UDP-based applications using the
   Real-Time Protocol (RTP).

"ECN to be for" -> "ECN to be used for"

3.1.5: Technical

Something about this sentence is odd:

   Applications that can provide this set of
   mechanisms, but wish to gain the benefits of using ECN, are
   encouraged to use a transport protocol that already supports ECN
   (such as TCP).

Was "can" -> "cannot" intended in the first line?

3.1.6: Editorial

   Normally a UDP source/
   destination port pair will set a single DSCP value for all packets
   belonging to a flow.

At end of sentence, insert "but multiple DSCPs can be used as described
later in this section" to set up 3rd paragraph in this section on the
DART draft.

3.1.7: Technical

   Some UDP applications are only expected to be deployed over network
   paths that use preprovisioned capacity or capacity reserved using
   dynamic provisioning, e.g., through the Resource Reservation Protocol
   (RSVP).  Multicast applications are also used with preprovisioned
   capacity (e.g., IPTV deployments within access networks).  These
   applications MAY choose not to implement any congestion control
   mechanism and instead rely on transmitting only on paths where the
   capacity is provisioned and reserved for this use.

I've seen attempts to "drive a Mack truck" through that "MAY" by
ignoring congestion control entirely (e.g., by writing a sentence
that parrots "preprovisioned capacity or capacity reserved using
dynamic provisioning").  That needs to be discouraged ;-).

I'd like to see some text added what an IETF protocol RFC SHOULD
do in order to take advantage of that MAY - RFC 7510 (MPLS over UDP)
may be a useful example to cite.  I'm tempted to ask for "MUST do"
here, but "SHOULD do" seems appropriate, with the potential wrath
of the IESG and/or the IETF community being possible consequences
of disregarding that "SHOULD" ;-).

3.1.9: Technical

   A tunnel SHOULD provide mechanisms to restrict the types of flows
   that may be carried by the tunnel.  For instance, a UDP tunnel
   designed to carry IP, needs to filter non-IP traffic at the ingress.
   This is particularly important when a generic tunnel encapsulation is
   used (e.g., one that encapsulates using an EtherType value).

This looks like an implicit recommendation that future encapsulation
protocol specifications that use EtherType SHOULD explicitly limit
the allowed EtherType values.  That's important enough that it should
be explicitly stated.

3.2: Technical

   Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
   rely upon network support for ICMP messages and is therefore
   considered more robust than standard PMTUD.

This should express a stronger caution about relying on ICMP "Packet
Too Big" messages.  Firewalls have a nasty proclivity to drop these,
they may not make it through NATs, and tunnel ingress nodes will
often discard them when generated within a tunnel.

For tunnels, PLPMTUD can be problematic, as adding probe packets
can easily force the tunnel into congestion case 3 in Section 3.1.9
(tunnel protocol designers tend to not want to go there), as well
as complicate the data path at the tunnel decapsulator.  Something
ought to be said about this, as tunnels are in a significantly worse
position wrt this concern by comparison to non-encapsulating UDP
applications.

4.1: Editorial

   Two styles of
   congestion control have been defined in the RFC-series:

I don't see citations of RFCs as examples of these two styles - they
should be added to the bullets introduced by the above text.

5.1: Technical

The discussion of "randomized" source ports should recommend
(lower case "should" or "recommend" is ok, IMHO) that they
come from the Dynamic Ports, also known as the Private or
Ephemeral Ports, 49152-65535 (cite RFC 6335 section 6).

5.2: Technical

Analogous to Section 3.2, this section should also strongly
caution against relying ICMP messages for anything.  See above
comment on section 3.2 for why.

6: Editorial

   UDP applications SHOULD provide protection from off-path data
   injection attacks using a pseudo-random source port or equivalent
   technique (see Section 5.1).

"pseudo-random" -> "randomized" to match term used in Section 5.1.

Some of the changes suggested above may affect the summary table in
Section 7.

10.2 Informative References: Technical

Should the following be normative?:
   [I-D.ietf-dart-dscp-rtp]
   [I-D.ietf-tsvwg-circuit-breaker]
The dart-dscp draft would be a downref, if normatively cited.

</WG chair hat OFF>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------