Last Call Review of draft-ietf-nvo3-mcast-framework-09
review-ietf-nvo3-mcast-framework-09-tsvart-lc-perkins-2017-09-21-00

Hi,

I’ve reviewed this document as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. When done at
the time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Summary:
This draft is on the right track but has open issues, described in the review.

Comments:
Overall this seems like a reasonably clearly written draft that describes the
problem space well, and outlines reasonable possible solutions. It seems to be
on the right track, but there are a couple of transport-related issues that
ought to be highlighted.

The major transport-related issue would seem to be congestion. Section 3.2
discuss this in terms of the load on the network generated by having to send
multiple copies of packets when emulating multicast. This is good, and well
written. However, it may be appropriate to explicitly mention that generating
multiple copies of the packets can cause congestion that would not be present
if native multicast were used (to be clear, this is not suggesting a new
problem or requiring new solutions, just asking for an explicit statement that
the replication can cause network congestion).

On a related note, the penultimate paragraph of Section 3.3 could usefully
mention that overload of the MSN could result in packet loss that will appear
as congestion to the endpoints.

One congestion related issue that is not discussed, and potentially affects
Sections 3.2 and 3.3, is that multicast congestion control algorithms based on
asynchronous layered coding (ALC) [RFC5775] perform rate adaptation by being
able to prune back the rate sent across certain branches of the multicast
distribution tree. An example is the FLUTE protocol [RFC6726]. While I expect
these congestion control protocols are safe to use in source-replicated or
MSN-replicated scenarios, they’ll certainly have sub-optimal performance in
such overlays, and will likely work better if native multicast is used in the
overlay. It might be appropriate to highlight this, since the large-scale
presence of applications using such congestion control schemes may drive the
choice of multicast support mechanism in the overlay.

The draft makes no mention of ECN. It could usefully cite
draft-ietf-tsvwg-ecn-encap-guidelines-09 and highlight that the encapsulation
mechanism chosen needs to support ECN if the multicast flows being encapsulated
make use of ECN. Similarly, if the multicast traffic sets the DSCP (DiffServ)
bits, will may need support from the overlay. Both points could potentially be
noted after the first paragraph of Section 3, where encapsulation options are
listed.

Editorial Nit:
Section 1.1: Please expand the acronym “TS” on first use (it’s not expanded
until Section 1.3, but is used in Section 1.1).

Regards,
Colin

--
Colin Perkins
https://csperkins.org/