Good morning everybody! Can you all hear the room?
", "time": "2022-11-08T09:30:07Z"}, {"author": "Jianwei Mao", "text": "Morning, I can :)
", "time": "2022-11-08T09:31:35Z"}, {"author": "David Schinazi", "text": "RFC 6126 is an example of an Independent Stream RFC that created IANA registries
", "time": "2022-11-08T09:45:07Z"}, {"author": "Richard Barnes", "text": "are there any actual game vendors involved? i note that Cullen is not one.
", "time": "2022-11-08T09:45:23Z"}, {"author": "David Schinazi", "text": "You can't play Doom on Cisco routers?
", "time": "2022-11-08T09:45:43Z"}, {"author": "Murray Kucherawy", "text": "Suppose this is adopted by the WG and gets all the way to Last Call, which is quiet. Could a critic make the argument that it doesn't really have IETF consensus?If yes, maybe ISE is the right way to go.
", "time": "2022-11-08T09:48:25Z"}, {"author": "Sergio Garcia Murillo", "text": "i will fix my audio and ask fore queue again
", "time": "2022-11-08T09:49:55Z"}, {"author": "Roni Even", "text": "I think that avt is not the gatekeeper. Payload subtype can be registered with Iana without avt review
", "time": "2022-11-08T09:51:15Z"}, {"author": "Jonathan Lennox", "text": "I've left you in the queue, let me know when you have it working
", "time": "2022-11-08T09:51:30Z"}, {"author": "Harald Alvestrand", "text": "Murray, this is a problem of anyhting in the IETF that doesn't generate significant controversy.
", "time": "2022-11-08T09:52:48Z"}, {"author": "Roni Even", "text": "Agree with Stephan and Magnus
", "time": "2022-11-08T09:53:11Z"}, {"author": "Roni Even", "text": "we did not have good result with clue which looks like similar procedure of dividing between the payload format and the protocol
", "time": "2022-11-08T09:55:40Z"}, {"author": "Richard Barnes", "text": "this all seems pretty theoretical without an actual community of implementors
", "time": "2022-11-08T09:56:44Z"}, {"author": "Harald Alvestrand", "text": "I think we explicitly disavowed internet-drafts as stable references - the series is labeled with \"this is not a stable reference\". One of the statements that is widely ignored, but it's still there.
", "time": "2022-11-08T09:59:10Z"}, {"author": "Murray Kucherawy", "text": "The shepherd should be following up with reviewers.
", "time": "2022-11-08T10:04:17Z"}, {"author": "Murray Kucherawy", "text": "Let me know if they're being unresponsive.
", "time": "2022-11-08T10:04:24Z"}, {"author": "Martin Thomson", "text": "I was just given notice about this talk. Why were the SFrame chairs not aware of this?
", "time": "2022-11-08T10:11:40Z"}, {"author": "Martin Thomson", "text": "mic: ^^ (I'm in another room, a long way away)
", "time": "2022-11-08T10:11:51Z"}, {"author": "David Schinazi", "text": "They don't know
", "time": "2022-11-08T10:12:25Z"}, {"author": "Murray Kucherawy", "text": "They thought it was closed. ;)
", "time": "2022-11-08T10:12:50Z"}, {"author": "Kirill Pugin", "text": "@Bernard, for RTP over QUIC demo - did you use streams of datagrams?
", "time": "2022-11-08T10:16:13Z"}, {"author": "Richard Barnes", "text": "shades of Alice in Wonderland
", "time": "2022-11-08T10:20:14Z"}, {"author": "Richard Barnes", "text": "are we at the end in general discussion or does Peter have more?
", "time": "2022-11-08T10:20:41Z"}, {"author": "Richard Barnes", "text": "we need PMTUD!
", "time": "2022-11-08T10:32:49Z"}, {"author": "Richard Barnes", "text": "it's a two-hop routing thing, Bernard
", "time": "2022-11-08T10:33:23Z"}, {"author": "Richard Barnes", "text": "to be clear, if you do SPacket, you don't need any of the fancy generic repacketizer stuff
", "time": "2022-11-08T10:46:38Z"}, {"author": "Peter Thatcher", "text": "SPacket has the same problem, as I pointed out. You still have the problem of converting a \"large RTP\" to \"small RTP\"
", "time": "2022-11-08T10:47:10Z"}, {"author": "Jonathan Lennox", "text": "But you still need to target the correct MTU
", "time": "2022-11-08T10:47:13Z"}, {"author": "Richard Barnes", "text": "@Peter - Fair point, i guess
", "time": "2022-11-08T10:47:42Z"}, {"author": "Richard Barnes", "text": "It seems like the underlying problem here is that RTP got over-dependent on being able to see codec internals, and now we need to fixthat
", "time": "2022-11-08T10:49:24Z"}, {"author": "Peter Thatcher", "text": "Yes
", "time": "2022-11-08T10:49:35Z"}, {"author": "Richard Barnes", "text": "so like let's go fix that?
", "time": "2022-11-08T10:49:49Z"}, {"author": "Peter Thatcher", "text": "What I proposed is a fix for that.
", "time": "2022-11-08T10:50:06Z"}, {"author": "Richard Barnes", "text": "@Peter - I agree, I'm just saying it's not an SFrame problem :)
", "time": "2022-11-08T10:50:22Z"}, {"author": "Peter Thatcher", "text": "It's a problem for anything that does e2e encryption.
", "time": "2022-11-08T10:50:46Z"}, {"author": "Richard Barnes", "text": "it's not even specific to E2E encryption, you have the same problem if a conference uses a codec your media switch doesn't know
", "time": "2022-11-08T10:51:19Z"}, {"author": "Richard Barnes", "text": "it's a general question of decoupling
", "time": "2022-11-08T10:51:28Z"}, {"author": "Peter Thatcher", "text": "This would work for that too.
", "time": "2022-11-08T10:51:46Z"}, {"author": "Peter Thatcher", "text": "I don't really care what doc we put it in or what reason we attach for doing it, as long as it solves the problem and we can put it somewhere.
", "time": "2022-11-08T10:54:19Z"}, {"author": "Sergio Garcia Murillo", "text": "+1 to richard
", "time": "2022-11-08T10:54:27Z"}, {"author": "Richard Barnes", "text": "draft-thatcher-avtcore-generic-repacketization
", "time": "2022-11-08T10:54:54Z"}, {"author": "Peter Thatcher", "text": "I call it whatever the group wants
", "time": "2022-11-08T10:55:19Z"}, {"author": "David Schinazi", "text": "Regardless of which layer/draft/WG we want to fix this in, there appear to be two classes of solutions: fragmentation or PMTUD. My personal take is: learn from the last time we did this, fragmentation does not work well. I don't know about which layer this should be fixed in, but PMTUD-like solutions will work better than fragmentation-like
", "time": "2022-11-08T10:56:22Z"}, {"author": "Richard Barnes", "text": "to be clear, i am not an SFrame chair
", "time": "2022-11-08T10:58:06Z"}, {"author": "Richard Barnes", "text": "SFrame is just the first instance of the problem
", "time": "2022-11-08T11:01:04Z"}, {"author": "David Schinazi", "text": "I this yet another instance of \"the network wants to help\" vs \"please just forward my bits in a generic way\"?
", "time": "2022-11-08T11:03:59Z"}, {"author": "Richard Barnes", "text": "+1 to Sergio's \"IRL\" point -- Webex has been happily using SPacket for a while now
", "time": "2022-11-08T11:04:40Z"}, {"author": "Mathis Engelbart", "text": "Latest version of RTP over QUIC includes the length field from RFC 4571
", "time": "2022-11-08T11:05:36Z"}, {"author": "David Schinazi", "text": "re: \"infinite MTU\", cf Joel's law of leaky abstractions
", "time": "2022-11-08T11:05:45Z"}, {"author": "Peter Thatcher", "text": "That's basically saying \"you can't use large RTP over QUIC if you're using SFrame\", which is one of its benefits.
", "time": "2022-11-08T11:06:01Z"}, {"author": "Peter Thatcher", "text": "(Equivalent to just giving up on Issue 29)
", "time": "2022-11-08T11:06:27Z"}, {"author": "Richard Barnes", "text": "No, \"You can't use large RTP over QUIC if you're using SFrame **and you're gatewaying to UDP\"
", "time": "2022-11-08T11:07:08Z"}, {"author": "Richard Barnes", "text": "**
", "time": "2022-11-08T11:07:14Z"}, {"author": "Roni Even", "text": "I think it is an extension to rtp over udp or tcp . It is application and implementation issues as long as the differences are clear. In the past it was better to use udp for video conferencing to allow for better error recovery at the receiver.
", "time": "2022-11-08T11:07:21Z"}, {"author": "Peter Thatcher", "text": "I want to use SFrame. I want to use RTP over QUIC. I want to have a server to speak both the old protocol and the new one. And you saying \"yeah, just don't do that\"?
", "time": "2022-11-08T11:08:25Z"}, {"author": "Richard Barnes", "text": "no, i think Sergio is saying, \"Use RTP/QUIC, use SFrame, but if you're in a situation where you have UDP receivers, send with a reasonable MTU\"
", "time": "2022-11-08T11:09:25Z"}, {"author": "Lorenzo Miniero", "text": "Yes, that's what I got too, which makes sense
", "time": "2022-11-08T11:09:42Z"}, {"author": "Roni Even", "text": "My view is do what you prefer just be aware of the advantages and disadvantages of each choice
", "time": "2022-11-08T11:09:48Z"}, {"author": "Richard Barnes", "text": "SFrame/RTP/QUIC, but with an MTU dial that gets turned down from \\infty when needed
", "time": "2022-11-08T11:09:51Z"}, {"author": "Jonathan Lennox", "text": "How we signal that you know that is an open problem, but something we could work on
", "time": "2022-11-08T11:10:02Z"}, {"author": "Sergio Garcia Murillo", "text": "yep
", "time": "2022-11-08T11:10:04Z"}, {"author": "Peter Thatcher", "text": "So I write a client that does \"SFrame with one frame per QUIC stream\", and then I connect that to an SFU. And then later I want to add support for older RTP clients. And now I have to go back to my RTP over QUIC clients and change them to not do \"one frame per QUIC stream\", which is a rather large change to it?
", "time": "2022-11-08T11:13:19Z"}, {"author": "Spencer Dawkins", "text": "Richard, I THINK the problem is (in a conference bridge environment) the definition of what MTU is reasonable can differ when someone joins or leaves the conference
", "time": "2022-11-08T11:13:46Z"}, {"author": "Spencer Dawkins", "text": "Does that make sense?
", "time": "2022-11-08T11:14:09Z"}, {"author": "Richard Barnes", "text": "Spencer: That's true in theory, but the point Sergio made (and I agree with) is that in practice it's not much of a problem
", "time": "2022-11-08T11:17:02Z"}, {"author": "Jonathan Lennox", "text": "It wasn't a problem, but if with RTP-over-QUIC we have finite vs. infinite it becomes one.
", "time": "2022-11-08T11:17:32Z"}, {"author": "Mathis Engelbart", "text": "Peter, you could still do one frame per stream, but put it into multiple RTP packets each prefixed with its length.
", "time": "2022-11-08T11:17:33Z"}, {"author": "Richard Barnes", "text": "Peter: Alas, legacy support is frequently more complex than supporting only the new hotness
", "time": "2022-11-08T11:18:14Z"}, {"author": "Peter Thatcher", "text": "Mathias: I can't packetize SFrame into multiple RTP packets. There's no defined way to do that (unless we adopt my draft, of course). Are you suggesting the solution is that the client has to do \"many SPackets in a QUIC Stream\" instead of \"SFrame in a QUIC stream\"?
", "time": "2022-11-08T11:21:14Z"}, {"author": "David Schinazi", "text": "You got mandate support for DATAGRAMS, and you honestly should. Streams are useful if you either (a) want something to be retransmitted or (b) want to send something atomic that doesn't fit in an MTU
", "time": "2022-11-08T11:23:40Z"}, {"author": "David Schinazi", "text": "You can* mandate
", "time": "2022-11-08T11:23:51Z"}, {"author": "Peter Thatcher", "text": "I don't want to put a video stream in datagrams. I want to put one video frame in a QUIC stream. I think it's a better fit.
", "time": "2022-11-08T11:24:17Z"}, {"author": "Giles Heron", "text": "what about using unreliable streams?
", "time": "2022-11-08T11:24:25Z"}, {"author": "Sergio Garcia Murillo", "text": "\"I want to put one video frame in a QUIC stream\" are you refering to put a video frame in a single rtp packet and then send it via an QUIC stream? or packetize a videl frame into multiple rtp packets and send them over a single quick stream?
", "time": "2022-11-08T11:26:38Z"}]