I completed another review of the draft-ietf-taps-transports-03 in the context of a "gap analysis” when thinking of multisource/multidestination (MS/MD) video sessions. What I mean by MS/MD is: a) multisource: for example real-time and progressive downloads combined with social media and user generated content (aka social television) b) multidestination: co-vieing of content either in real-time or via progressive downloads (binging on Netflix)
The draft is good and is supplying I think a common way of evaluating the different transport protocols. I want to highlight just a few items that i think are still missing 1. more details on secure transports and 2. a good discussion of what reliable transport means (in the sense of RMT and more). See details below. 1. Secure transports: I think the inclusion of (D)TLS will be good as it will highlight the needs for secure transports to ensure some privacy. Also discussing TCP-AO, TCP-INC and IPSEC would make it complete. However in the context of MS/MD I think we should make sure we look into the delays that these protocols incur. I guess we can make the assumption that all parties in the MS/MD will use the same transport so would all experience simlar encryption delays. I remember that at the beginning of the WG we had made no such assumption on the use of uniform transports across sessions. Maybe we need a discussion? List what do you think? 2. Reliable transport: I have a issue with TCP being put as completely reliable; I understand why it is there but in terms of the MS/MD application TCP is not "fully reliable" it's actually not reliable especially when it comes to latency. I think the text could be enhanced by the mention of this. Video stops and sync is lost between the streams (in my world we call that "buffering events") and the quality of experience of viewing groups will be greatly impacted. For realtime I suppose we can look into things like WebRTC which I do not think is being directed at things other than voice/video conferencing right now but of course could be extended. This also implies the use of a browser which is not always the case. But for progressive downloads which is most of the consumed video and for the content to keeps in sync and relevant (when one stream stops the others become out of scope) there needs to be more reliability. Of course the FEC protocols developed for RMT are still valid even if we look at multiple unicast sessions and the document could refer to that? I also think that non-block approaches (newer sliding window codes) could be considered. And of course we should mention how congestion control fits in all of this :-) Finally Table 4.1 has a number of features that are being addressed by existing protocols which is fine. Do we want have a paragraph on features that are needed but could be supplied by either not fully standardized protocols or protocols developed in the future (see reliability above)? But in any case great job and looking forward to discuss it in Dallas. Marie-José Marie-Jose Montpetit, Ph.D. [email protected] @SocialTVMIT
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
