TSVAREA @ IETF-93 with 1 sessions Thursday, July 23, 2015 (CEST) 17:40-19:10 Thursday Afternoon session III Grand Hilton Ballroom * Administrativa (5 minutes) - Note Well - Blue Sheets - Jabber Scribes - Agenda Bashing - Welcome by the TSV ADs * Transport Area and NOMCOM (10 minutes) Spencer Dawkins and Martin Stiemerling * MPEG Media Transport Protocol (MMTP) [1] (10 minutes and 5 minutes Q&A) Imed Bouazizi Matt Mathis: I didn't hear anything about the outer layer, UDP? IB: The initial thought was UDP, and there has been thought about MMTP over WebSockets. Matt: Embedded in this are some hard unsolved problems. How do you deal with congestion control for something like a tunnel, where you are unaware of what you are carrying. A tunnel that doesn't own responsibility for its content. We don't really know even the right questions to ask. IB: Payload types are limited, we know what we are delivering. Mirja: Additional requirements beyond RTP seem to indicate we could add features to RTP to solve these use cases. IB: We thought about this, MPEG2 over RTP was done, and the RFC itself indicated it was a bad design, overwriting synchronisation for example. There are fundamental differences to RTP, which led to this conclusion. But we're here to see what is possible. Gorry: Thanks for showing up. Is there room to change this? IB: We are open to changing this, this is just a starting point. If this is done wrong, it could be disastrous. Lars: Your starting point looks like a finished system design. You say RTP doesn't work, but we don't understand why. As an individual, it sounds like the current proposal is unlikely to resemble what comes out of an IETF effort. Many of the parts here seem like we have solutions for. I'd like to know why RTP doesn't work. IB: I tried to start explaining why RTP was not a solution, but perhaps didn't cover that well enough. Next steps: list conversation, and chairs/Gorry will confer. * Enablers for Transport Layer Protocol Evolution [2] (20 minutes and 10 minutes Q&A) TBD Brian Trammell: There seems to be a preoccupation in this design with not trusting the transport protocol. I wonder why that seems to be a design principal? S: Because fast evolution probably implies buggy and dangerous evolution. IETF protocols should be trusted by default, because they should be fine. Brian: I can implement TCP on SPUD, but I don't think you should trust it at all. You have a set of requirements and pointing at other work; it is a coherent vision of the future. This seems hard, and dystopian. Hard because trust and policy component becomes the attack surface. To make this work, you have to solve key distribution, and if you can solve that, it can be applied to better things. "It shall be possible for end host to opt out of middlebox cooperation"; this is very scary. I don't think that seems like the internet. S: I think I should have said it should be possible for the end-host to opt-in. Brian: At a minimum. Christian Huitema: This has a similar motivation to SPUD. I have a hard time believing this would be good for the internet. The hard problem is that if we want evolution, the network needs to not trust the e2e transport, and given that if we believe the network has to trust the e2e transport or else it will collapse, that's fragile. So we should figure out how to make the network stable in the face of transports we cannot trust. There are ways to do that. Say if you do something as simple as fair queueing (for example), then it makes it impossible for users to damage each other; one user can only hurt themselves. This becomes a generic contract, which is probably much easier than looking at exactly what is implemented everywhere. Expressing the problem in the terms of how to prevent congestion is more likely to give a concrete architecture, than having an abstract discussion of abstract middleboxes. [name missed; chinese]: If you have multiple cascaded middleboxes, how do you talk to one in the middle of the path? S: That is far from trivial. I don't have a solution. Lars: If you have resource constraints, you either do something like this, or you increase capacity. This will never get more performance; it's all about policing. Building an architecture around administering scarcity isn't a good idea. S: So why do we have tiny caps in mobile? Is that just a pricing trick? Brian: The trust and policy controller will be the key for everything that has a capability associated, yes? For how much that PKI will cost to operate and/or build, how much capacity can I build? That's going to be seriously expensive. The controls will be a lot of overhead, as will the key management be. Also, there are so many evil things that can be done with it. Another way of looking at it, who is going to build that controller? Matt: One thing influencing internet design today is that the trajectories for memory and bandwidth costs have different slopes, memory goes as moore's law squared. In switches, queueing time is going down, because the memory is too expensive. The state in the network for running this is going to blow up. We can do AQM at the edge, but the core runs drop tail. S: There are controllers in cellular... Matt: They are quite close to the edge. * Open discussion about evolution of transport protocols remaining time. [1] http://datatracker.ietf.org/doc/draft-bouazizi-tsvwg-mmtp/ [2] https://tools.ietf.org/html/draft-mihaly-enablers-for-tlp-evolution-00 Matt: I tried to have the AD discussion inside Google; support is a euphamism if it doesn't contain the word 'financial'. That raises the spectre of conflict of interest, which implies doing something at, for example, ISOC level, to provide some isolation. Aaron Falk: Jabber query about where the previous discussion would continue. Martin: That should continue on tsvarea. Aaron: I'd like to point out, that the whole stack evolution thing is going to bring much interesting work to the IETF; it already has. That should make it an exciting time to be an AD in Transport, especially for researchers. Spencer: We used to be unable to deploy new transports, but that is no longer true.