[Mops] AD review of draft-ietf-mops-streaming-opcons-09

["Eric Vyncke (evyncke)" <[e-mail]>]

As usual, before going to the next publication step (the IETF last call), I do my own AD review. Sorry for this belated review but "just in time" for the MOPS meeting at IETF-113 ;-)



First, thank you to Jake, Ali, and Spencer for writing the document and to the whole WG for providing comments and reviews. The document is easy to read and is also an excellent tutorial, I learned a lot around the interactions of app & transport layer interactions.



Please find below some comments, feel free to ignore my suggestions but I would appreciate a reply on all of them. I also have an action item about 'living documents'...



Hope this helps



Regards



-éric



# Generic nits



Please select "internet" or "Internet" and be consistent ;-)



# Section 1



" This document examines networking issues" but it seems that the document goes beyond pure networking issue (e.g., transport layer)



" simultaneous consumption by the client" unsure whether "simultaneous" is the right word as there is a delay but I have no suggestion :-(



# Section 2



" expected to grow to 82% by 2022" but we are in 2022... better provide numbers for 2021 if they are available (and now I read that the source of the info is my own employer :-O )



While I am not an expert, I am surprised by the acceptable latency numbers, I would have written 100 msec for videoconference and "couple of seconds" for streaming live events. Video streaming (netflix like) is indeed several seconds. But, I am trusting the authors on their statement. Section 4.2 explains a little more those numbers so a forward reference to section 4 would be beneficial.



" reliable media using HTTP over TCP," should MOQ be cited here ? or HTTP/3 over QUIC ?



In the advantage of HTTP, would the acceptance of HTTP by middle box be another plus ?



# Section 3.2.1



" Know Your Network Traffic" what is "your" in this section ? My network used by other parties (server and consumer) to transfer streaming video ? My network as the servers, layer-3, and consumers are all in my administrative domain? Suggest removing the 'your'



# Section 3.6



Unsure whether the end part of this section is relevant to the document as it is rather anecdotical.



# Section 3.7



In " it was observed that port utilization increased" port is ambiguous: is it IXP physical interface ? UDP/TCP ports ? or something else ?



In the same paragraph, an explanation to the explanation would be welcome.



# Section 5.3



Unsure whether "server-player systems" is well understood by the readers.



Nit: "some metric monitored by the client" should the plural form be used ?



# Section 5.4



Wow, another IAB " Interactive Advertising Bureau". Amazing ecosystem.



# Section 5.5



Same comment as for section 1, "networking issues" actually means something broader than the plain layer-3. Suggest introducing the shortcut in the terminology part of section 1, e.g., "this document uses the wording networking issues to represent the conjunction of IP and transport layers" ?



# Section 5.6



The very first sentence is mostly unparseable due to its length (7 lines). Please consider splitting it.



# Section 5.6.1



QoE is introduced here but its expansion has already been used before, consider introducing QoE earlier.



This section and the next one should be a list with 2 bullets rather than 2 sections to make the text more readable.



# Section 5.7



Unsure whether this section really belongs to section 5 based on its contents vs. section 5 title. Especially when placed just before section 6, which is about transport protocols.



# Section 6.3



Please consider using the same wording for the title as for 6.2 and 6.1



Who is "we" in " We do have experience" ?



While I share some concerns about deploying a new transport in user space as opposed to more stable and controlled kernel space, I wonder whether this paragraph is relevant in this document. Does it bring any value ? If no, then please remove it.



# Section 7.1



Based on the title it is unclear whether this section also covers "app layer encryption", I guess no but this should be made clear (perhaps high in section 7 by stating that this doc does not cover app layer encryption).



# Section 7.2



Last paragraph, while I understand why some mobile providers wants "to lower quality" it would be easier for the reader to understand if the text said "in order to reduce the bandwidth on expensive links, some operators want to lower the quality".



# Section 7.3



Please consider introducing the DPI acronym earlier in the text as its expansion is used before.



Authors may also want to refer to drafts about the same considerations (i.e., end-to-end crypto hindering operations).



# Section 8



Living document concept is coming often as a topic for the IETF documents... and we have yet to find a right way of doing it. Expect a lot of discussions on this area and I have no solution to offer. Rather than using a tiny URL, why not a github one (hoping to have more control on it). We can probably live with this pending issue until the IESG evaluation. As the responsible AD, I will probe other IESG/IAB members for their best current advice on this topic.