IETF 89 London - Thursday, March 6, 2014 Minutes of AVTEXT WG Meeting Chairs: Keith Drage and Jonathan Lennox Minute Takers: Emil Ivov and Roni Even MP3 Recording: http://www.ietf.org/audio/ietf89/ietf89-buckingham-20140306-1520-pm2.mp3 http://www.ietf.org/audio/ietf89/ietf89-buckingham-20140306-1700-pm3.mp3 Meetecho Recording: http://ietf89.conf.meetecho.com/index.php/Recorded_Sessions#AVTEXT Slides: https://datatracker.ietf.org/meeting/89/materials.html#avtext Note Well, Agenda, and Status Update Chairs: Agenda bashing Mostly hoping to finish taxonomy today Next we have Media Stream Pause/Resume Finally: Splicing notification Status:Two drafts in rfc-ed queue. We are done with them. Also here's some tea for Gonzalo because we are worried he didn't have enough. Taxonomy draft Bo Burman et. al. (Bo presenting) Slide 1: Hello Slide 2: Changes since 00 Mostly editorial Slide 3: Goal Brief summary and look for WG consensus on way forward Slide 4 and 5: Concepts Stream and Transformation Slide 6: Media Chain Multiple Transformations and Multiple Streams. Bernard Aboba: I am puzzled by the media encoder that seems to be doing both SVC and non-SVC Bo: Don't take it too literally but here one of them is basically just the base layer. "Encoded" stream can be decoded on its own, "dependent stream" needs something else. Slide 7: We introduced a few more transport concepts. It's no longer a single transformation. Slide 8: Receiver Emil Ivov: where is RED 2198? Magnus Westerlund: You just put two inputs on the packetizer and a single output. So RED is at the transport. Slide 9: Communication Entities and Sessions Mo Zanaty: Is endpoint a single host? A single transport address? Bo: Yes. "Host" is also not very well defines. Mo: And you can have multiple sources inside an endpoint. Bo: yes. Paul Kyzivat: Is the participant a person? Bo: Not necessarily. It could be a room. Jonathan Lennox [as chair]: Please review the definition and make sure it means what you think it should mean. Harald Alvestrand: You are not using the word "flow" anywhere right? Bo: No Harald is happy Christian Groves: In CLUE, we have a definition of participant and endpoint, and it's reversed from this. Bo: We need to review this. Jonathan [as chair]: There are two issues. First, do the definitions in the draft reflect the concepts we want; and second, are the names we have given them good names for these concepts. Naming things is hard; getting definitions right is hard too, but in a different way. Slide 10: RFC 6190. Single Session Transmission and MST Proposal (not in draft): Change names to Single Stream Transmission and Multiple Stream Transmission Bernard Aboba: Alex was suggesting that we keep the definition of the acronyms but also define new things. Don't change SST to mean single stream. That confuses people. Mo Zanaty: Yes agreed. We should be careful about reusing existing terms, because they're so blurred. And besides we don't really mean transmission by T. We should rather say single SSRC packetization, single-encoding packetization. Packetization is a better word, we're not talking about transmission. Jonathan Lennox from the floor: The important distinction is single or multiple, that's what we need to focus on. How the streams are distributed to sessions is important but secondary. Naming things is hard, better to avoid acronym collisions, if you have suggestions for alternate names send them to the list. Mo: We should first clarify concepts on standardized things (even if unused) and only then move to non-standard but used things. Jonathan still from the floor: When 6190 was being written, we didn't think there was a use for an MST in a single session. That has changed since so that's why we need to look at this again. Bernard: beware of using "packetization". SST and MST in 6190 are packetized differently, but HEVC they're packetized the same. Mo: By packetization I really meant just the act of putting stuff into packet. Not things like a packetization-mode. Magnus: I think this discussion is all about how you structure your packet streams for a single scalable encoding. Bo: But we're able to continue this discussion using terminology from the taxonomy document, so I've reached my goal. Bo: conclusion: need more discussion also in the H.265 payload formats they use SST and MST. Bernard Aboba: They changed that in the most recent draft so it should be OK Bo: OK, so I'd like to propose to the room that the 6190 SST and MST should be clarified in the taxonomy terms. H.265 should follow suit. No objection from the room, agreement from H.265 payload format authors. Slide 11: Way forward. Is everyone OK with where we are going? Are we ready for WGLC? Magnus: Do we need to add detailed concepts for SST and MST (and their relation with sessions) in taxonomy terms, or is what's in the draft sufficient? Bo: if it has to be explained in the taxonomy then yes, possibly. The latter part of the draft is less reviewed, so I encourage reviewers. We want much more input. Keith: Who read this? ... [Some hands go up] There seems to be reasonable review within the group. We need other groups to review the draft, and we to go through the drafts that use this and see whether they have everything they need and whether they comply. We have a possibly-incomplete list of drafts [http://www.ietf.org/proceedings/89/slides/slides-89-avtext-4.ppt] that would need to be reviewed. Some of them may be too late to change. Jonathan: There're two directions review needs to go in. First, does the draft need to be changed for taxonomy; and second, does taxonomy need to be updated for all the concepts a draft needs. Mo and others discussing whether the list should be "all drafts in RAI". Or not ones that are signaling-only? If this draft defines "endpoint" and "participant" it touches everything. Keith: If we review the major ones that could probably be enough for starters. Mo: We should really concentrate on the drafts that use the low level RTP concepts. Mary: I think the groups that started this discussion (e.g. CLUE) are an obvious start. Jonathan: If you see your document on this slide, make sure you go through it and update. Keith: Is STRAW RTCP currently on this list? Jonathan: No, should be added. Christian Groves: XCON document also has a taxonomy Mary: The Xcon docs are probably not a concern. we don't go to that level Jonathan: I agree with Mo, the Endpoint and Participant issues are secondary. Mark Duckworth: I think I saw CLUE framework draft there. I think we don't use the taxonomy terminology, maybe it should Jonathan: Should anything in CLUE other than RTP-usage be on this list? Mary: Signaling should reference taxonomy. Roni Even: We started this because of inconsistencies between SDP and RTP. All documents that have gone there are potential customers to taxonomy Suhas: I would recommend that SDP documents in MMUSIC look through taxonomy. I will be updating sdp-mux-attributes based on taxonomy. Jonathan: There are a lot of documents here, we're not asking anyone to review all of them, but hopefully people will review one or two. Suhas: I will do sdp-mux-attributes, you can also assign me something randomly. Jonathan (to WebRTC people in the room): you should also look at WebRTC documents, or related MMUSIC drafts. JSEP may need to be on the list, or MSID. Magnus: The RTP usage document already uses taxonomy. We'll make sure it's aligned though. I will also update the topologies document in AVTCORE to use taxonomy. Paul Kyzivat: Harald asked about flows earlier. Can he clarify? Magnus: This comes from the RTCWeb QoS document, one or more packet streams needs to be in a QoS context over a particular 5-tuple. Bo: Does a single packet stream have multiple flows? Magnus: The other way around, e.g. an encoded stream and its associated retransmission stream might have one QoS marking, but other packet streams might have different ones. Bo: It might be useful to have another name there, then. Magnus: I don't know if we need to bring it into taxonomy. Keith: Is the QoS document adopted yet as a WG draft? Magnus: Currently not. Harald: The most relevant document has been adopted in TSVWG, or is about to be. We should avoid inventing new terms, just use packet stream and group of packet streams. Jonathan: Do we need a term for things flowing between the same 5-tuple? Do we need terms for things over the same 5 tuple but of different nature (like SCTP and RTP)? Magnus: I agree we should look at that. Jonathan: Does DART need to be aware of taxonomy, and vice-versa? Mo: DART would like a concept of packet streams sharing a transport association. Harald: I promise to review all my own docs. But other eyes are very welcome. Mo: Also I suggest we add a quick summary section of all the key parts and terms that are causing confusion today. I can provide some text. Jonathan: That's a good idea, provided there actually is a common list. So I agree if we agree on what these terms are. Keith: Do we need to get in touch with the authors of the QoS document? no answer Jonathan: Should we try to send around a mail to urge others to check? Magnus: Please send mail to WG lists. Mary Barnes: Worth noting that all the people that need to supervise that are in this room so they should probably take note right now. (Mary lists CLUE authors, who are in the room.) Colin Perkins: Why don't you just mail the authors and suggest they review this, as part of the normal WG review process? Jonathan Lennox: The taxonomy doc has a glossary that maps terms from other working groups. Those other WGs should review this, and make sure they're correct. If any current work can change to use terminology from Taxonomy, we should remove the equivalences section from Taxonomy. Keith: Bo, you happy with the feedback Bo: Very! MOVING ON TO NEXT AGENDA ITEM draft-westerlund-avtext-rtp-stream-pause-05nard Aboba: This is useful. With respect to layered coding this only works with multi-stream transmission. Jonathan, Bo: that's right. There's no way to use this to do layer selection for single-stream transmission. You could pause the whole stream though. Slide 5-8: example flows Slide 9: One note: signaling for existing TMMBR should be enough. No need for new signaling messages. For new messages we have new signaling. Slide 10: Bo: Can we adopt this? Keith: Roni, you've had a lot to say in the past -- does this make sense? Roni: Yes it does. We've merged our documents. Keith: Other objections? Keith: Who's read the document? [6-7] Keith: Is this a suitable topic for working group adoption? [yes] Show of hands for adoption? [some] against adoption? [none] Bernard Aboba: If we do this are we going to push against codec specific mechanisms Jonathan: Like? Bernard: Layer-drop messages. Roni: This is also what we did with 5104 with codec-independent messages. Bo: This is only operating on SSRC levels, so you can do anything that can be expressed on that layer, but no finer-granularity control. Jonathan: the other thing I'd like clarity on is when you'd use this vs. signaling-level mechanisms like marking a stream sendonly/recvonly. Keith: would we want to ask PAYLOAD whether they want to place any restrictions on this, or modify any of their codec documents to use this? [No enthusiasm] Keith: We'll go to the AD and ask for a milestone. Keith: Does anyone have an alternative proposal in mind? Harald: I am doing something similar through SDP for MSIDs ... but I don't think it's a conflict. Jonathan: Both drafts need to be clear on their scope, and make sure they agree their scopes are non-overlapping. Emil: With WebRTC many people are likely to use data channels for this. Is this OK? Magnus: Yeah. We can ignore them. WebRTC could consider adopting this draft at some point. Keith: Is the IPR a concern for anyone? [no concern is expressed] Keith: show of hands for all those who want this as a WG draft [some hands] Keith: all against? [none] Keith: OK, we have consensus for adopting. ========================== Roni Even for: draft-xia-avtext-rtp-notification-03 RTP splicing. Roni: Are there any open issues? Dave Oran: Does the document say what happens if you lose one of those messages? Roni: It does. You are supposed to send "enough" so that does not happen. Dave: So the mixer falls back to regular mixing? Roni: It simply does not do splicing. Dave, Roni, Jonathan: more back and forth on what happens when splicing info is lost Roni: The splicing architecture is in RFC 6828. Colin Perkins: Don't remember what's in the draft. But there's always a chance splicing info is lost, however you send it, so it doesn't really matter what you do and we should just say you keep playing the original stream Keith: What are the differences from the presentation at the previous meeting? Roni: It's the same Keith: As I recall, at the last meeting people thought it was a reasonable technical solution but it wasn't clear there was interest in the document. Jonathan: The problem is this group doesn't have much visibility into the IPTV space, particularly an IPTV community that mostly doesn't speak English. The feedback I've heard from the authors is that's where the interest in this work is coming from. So it's hard for us to judge how much people want it. Colin Perkins: There's no harm in doing it anyway. Worst-case scenario: we end up with something no one uses. Big deal. So I am not against doing this. Jonathan: If we did adopt this, are there other people would be willing to comment and review? Or other people doing the same thing differently? Dave: We do. We won't implement this. We have a different approach, which we're not interested in standardizing. But we don't care what you do, so go ahead. The people I know who are doing this for money are using SCT135 markers, in MPEG2 Transport Streams. Roni: That only works if you're using MPEG2 Transport Streams, this works if you're not using them. Dave: Right. Roni: That's what this community is doing. Jonathan: Ok. Seems we have consensus on "harmless at worst". Keith: I'd like to see more organizations interested in this document. Jonathan: But they don't speak English (this appears to be mostly done by non-anglophone communities) so that's not easy. Some discussion on AD-sponsoring this. Roni: This complements RFC 6828 which was done in AVTEXT. Keith: let's take it on the list Some disagreement. Jonathan: OK let's see how the room feels. Raise your hand if you think we could adopt it. [Some hands go up] Jonathan: against? [One or two.] Jonathan: Why? Technical objections, or just cycles? Concerns for lost cycles expressed by Justin Uberti Roni: But we don't have any other documents in the group. Jonathan: We'll talk to the AD and to the list and see how to move forward. We'll also hope that non-English speaking people that use this actually come and provide more cycles to work on this. Keith: OK we are done! Adjourn