Update for Mike English WGLC comments on Introduction #94
Conversation
Thanks for taking a crack at this, Spencer. It looks like a worthwhile update to me that improves the doc wrt the issue Mike raised. But I do think this removes the definition of streaming that was a prior suggestion, and on looking it seems like webrtc and rtp-specific operational considerations are notably light. We point at these in a few places but maybe we need a brief explanation of why it's not in scope or not addressed.
(I think the answer is that there's not yet a lot of operational experience with using these for media streaming over the internet, as opposed to conferencing or walled-garden deployments (maybe? or is this usually raw mpeg udp?), but I'm not quite sure.)
I guess I'm thinking to accept this pr, but maybe we should also open a new issue about adding a paragraph to address missing considerations about webrtc or rtp more generally, tho I'm really not sure. @englishm-ietf, any opinions here?
|
I am OK with the changes @SpencerDawkins. A minor suggestion is to start with streaming media (not video) but then it is ok to keep using video. And wrt non-HTTP/ABR streaming approaches, I agree with @GrumpyOldTroll that there is not really much to report. All those methods with RTP or not (like RTSP streaming or UDP/RTP multicast IPTV) required pretty much a solid bandwidth, reserved capacity or some sort of QoS, which we are not really talking about in this document. Sure, RTSP has some rate-control mechanisms (mostly on the sender side as opposed to the client side, which is not important for this discussion), but who does really have some operational data on it? People started getting concerned about streaming traffic when it got out of the walled gardens (i.e., when we started using CDNs and HTTP for video all over the internet). |
|
I understand the comments from both @GrumpyOldTroll and @acbegen. I'll send another commit, and let people check my work. |
|
Thank you so much @SpencerDawkins for taking the time to address my comments here. Sorry I've been delayed in responding. I do think your first pass definitely moves things in the direction of greater clarity. I also agree with @GrumpyOldTroll that we could use at least some explanation about the relationship between HTTP chunked streaming (the common case that this document mostly focuses on) and other forms of media streaming like UDP/RTP. @acbegen 's comment already contains an important observations that's probably worth including: namely that streaming media at much lower latencies without a reliable transport protocol typically requires more controlled network conditions to preserve high QoE. I think some language about how HTTP chunked streaming has become predominate specifically due to the cachability of of the delivered objects might be another. If we include language like that about what I'll loosely generalize as the "UDP/RTP" vs "HTTP chunked streaming" approaches, we could also provide readers with useful context for the types of issues likely to be encountered with WebRTC and/or QUIC as new methods of delivery are explored where the transport protocol may not provide the same reliability guarantees as TCP and more responsibility for mitigating the effects of network conditions on the open Internet may fall to applications. It may be a bit late in this document's lifecycle to add much content here, but perhaps we can at least hint at future work with how we frame the relationship between the different approaches. Thank you again for considering my feedback and taking the time to make these updates. |
|
RTP with RTCP is theoretically supposed to help with the reserved capacity and rmcat is trying to write up approaches that should work (as experimental and informational so far). In theory this should of course work fine, but in terms of operational considerations for streaming over the internet this way, my knowledge is certainly very fuzzy, and from what little I know I somewhat expect that particular operational issues here are off in the weeds of codec-specific encoding and decoding issues around loss and reordering, in a way that abr with reliable segment transfer is not. There might be someone out there who knows more. (e.g. maybe someone like juberti could write a section like this if we asked nicely and we think it needs including?) I think I slightly prefer declaring it out of scope for this doc and coming up with an excuse we can sign onto with a straight face, but I feel a little dirty about that preference, and I'm not sure it's quite the same as doing the right thing. |
Oh, please, let me clean @GrumpyOldTroll off. The right way forward in my mind is to say something like "this document is mostly about HTTP chunked streaming, because that's so heavily used. We do mention RTP, but we can't give the same quality of guidance for that traffic, and much of what we can say is heavily dependent on the type of codec being used". Anyone who thinks that we can give that guidance is welcome to send text, of course. Jake, do you still need to be cleaned off more? |
|
@SpencerDawkins I'd agree that simply qualifying the limitations of the document (and stating why we think the current focus/scope is a reasonable one) is the appropriate course to take at this point. Trying to solicit new text from additional contributors who have not already been engaged doesn't seem advisable at this stage and I do not have the bandwidth to contribute anything significant right now. Thank you again for your work on these updates. |
|
Works for me :) Thanks. |
Also adding Chris Lemmons a in Acks section.
|
@SpencerDawkins THINKS this addresses the last call comments that we've received on -07, plus discussion to date about those comments. I'll submit this as -08. |
@englishm-ietf, could you let us know if this PR does a better job of describing the scope of the document? And thank you for your comments!