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

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-nvo3-mcast-framework-09-tsvart-lc-perkins-2017-09-21

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/