Transcript Day 1: Technical Sessions
|Slides||IAB Workshop on Stack Evolution in a Middlebox Internet (semiws) Team|
|Title||Transcript Day 1: Technical Sessions|
|Abstract||Transcript Day 1: Technical Sessions|
|Other versions||plain text|
Technical Session 1: The bigger picture: what is the problem? how did we get here? (11:20 - 12:45) -------------------- -------------------- Intro slides (2-5) --- - Take note of earlier work, including RFC 5218 and RFC 7305. - NAT has been recognized as a challenge to the Internet architecture for a very long time. - IAB Stack Evolution Program is the reason for the workshop. Can we find a way forward in light of today's Internet. - The waist of the hourglass has become HTTP or HTTPS. Some people disagreed with this picture, especially the picture needs to recognize various types of tunnels and the increased demand for encryption. Ken's slides --- - The "path" (as distinct from the "route") is becoming a first class concept. - Incentives are aligning. - Recognize need for evolution and inovation. - Components of a solution include a framework for composing end-to-end functions and a mechanism for negotiate (or at least determine) path characteristics. - Fine-grained control - Integrate security Christian's slides - Secure Transport Tussle --- - So far, the middleboxes are winning; could not deploy ECN! - Need to focus on the incentives for the people that are choosing to deploy middleboxes. We see partial success with UNSAF NAT Traversal. - UDP w/ encryption (e.g., QUIK) is a secure transport. HTTPS is a fallback where UDP is blocked. - Gaming is even more sensitive to latency than VoIP. - Deploy on the Internet of today, and the network will evolve to do things better for that application if it becomes * jana: If you don't align incentives, things don't move. Jim Getty's "downward deployability" * brian: webrtc is that Thaler's slides - It's all about incentives --- - slide 15: RFC 5218 - it is best if there are significant positive net value at each organization where a change is required. - slide 16: Tussles stem from conflicting incentives in a free market. - e2e protocol innovation - some middleboxes that provide optimization - firewalls are worried about untrusted entities - inter-protocol proxies are inherent in innovation * Ken: what does the tussle look like for end users? * Dave: metrics in Consumer Reports about which ISP to use * Brandon: not always provider vs. provider, it might also be Akamai * Dave: might be multiple CDN providers in competition * Bob: also departments inside a single ISP * Christian: history of this backfiring * Brian: if it's in hardware, by the time you realize it's a problem, nobody knows about it anymore * Christian: tussle between a smart network and a high-capacity simple network * Erik: in addition to security, there is also protection for a business model or current revenue stream. * Black: heading toward edges, TURN servers are now price of doing business, could be a way to make progress * Ted: TURN servers have to be on the public side when deployed, but don't always have to be deployed * Black: increase the incentives to deploy TURN * Wing: TURN servers don't solve. If i don't trust the entity, I won't allow it. Bittorrent over WebRTC. Enterprise's job is to provide "safe" bits. Policies are more complex than "make WebRTC work". Definitions of "good" and "bad" are fuzzy. End systems and middleboxes both have a role in the final acceptable solution. * Christian: adding VoIP to existing FW was hard; keep media gateways separate. Adding more middleboxes to "safely" transition a firewall is the wrong architecture. It does not scale for each new application. * Joe: we should at least try to do e2e, not send everything through TURN * Black: TURN servers might be a place to add value, though * Ted: TURN server allows application to make a choice about the path, client gets to say it wants a *service* on the path. Also policy breaks path when it might or might not be good. Split-client proxy approach. DPI will be needed to determine what is on-path if we do not develop a different abstraction of the network stack. We need an API to the path to make progress. * Bob: middleboxes that are needed for inter-protocol are deployed as part of a transition, but then they never go away. * Eliot: what is an endpoint? * Jana: when the middle don't have options, they add what looks like a new endpoint. * Erik: A very different example of middleboxes are used to improve performance over a satellite link. They try very hard to be transparent, but they sometimes break things. * Thaler: NAT64 doesn't work for anything but UDP or TCP * Brian: it's a change to the contract * Christian: Skype relays compare to NAT64 relays. open relays never work, never deployed because incentives don't align. Skype can charge for relays, so there was strong incentive. * Jana: i've stopped thinking about TCP as e2e, it's happens for anything that gets popular * Eliot: smart objects are also "the user". how do you empower a lightbulb? * Mirja: control over middleboxes to client, but is there a different class of middlebox? there are at least two classes of middleboxes -- ones where the end point can get some control and and ones where they cannot. * Thaler: yes. attackers on the inside. this is why there's a tussle. * Black: think about smart objects a bit differently. The end user is actually the person that deploys the lightbulb. But the person that installs it might use the API at the lightbulb server. - slide 17: Upper layer protocols: - want it to work everywhere (needs to look like HTTPS) - want to be efficient (throughput, latency, power, and so on) - want to be as simple as possible (easy to diagnose, maintain, ands mall footprint) -> Can get one or two, but not all three. People make tradeoffs. * Christian: it's not conflicting incentives, we have to make engineering choices. if you have a layer that allows you to pick a server closer to you, it decreases latency, so adding layers doesn't always add latency * Brandon: path API * Gorry: layers may be a figment of protocol design seen by network designers, not elsewhere. * Joe: adding a layer doesn't always require added round trips * Jana: layers might not need bits on the wire. they might be notional * Michael: the incentive is to get it to be as efficient as possible * Thaler: example is happy eyeballs * Costen: typically people think about it as fallbacks from optimal * Thaler: other people will take UDP as a baseline * Brandon: Flexibility / deployability might be the tradeoff * Eliot: sometimes the scope is Enterprise, sometimes it's the House * Christian: too many fallbacks are bad; it brings too much complexity. * Brian/Eliot: "scope" is also a dimension to the tradeoff. * Aaron: it is not back and white -- need to make compromises in all of these dimensions. * Colin: people will not agree on the dimensions that are part of the tradeoff. * Gorry: robustness is also important. And, need to avoid an arms race. * Erik: operational complexity is also important, and it really needs tools. * Mirja: "incentives" is the wrong word. Rather, we need to think about these as requirements for protocol designers. Incentives apply to adoption of the protocol. Felipe's slide (19) presented by Brian --- - Problem 1: Middleboxes are common - They enhance network functionality - Not always opaque * Aaron: Jim has done work * Christian: ad insertion something people want? * Bob: only in the US do people buy their own CPE * Christian: cable companies aren't trusted * Bob: NFV moving SPs to software, which should make things update more frequently, but can't rely on it * Spencer: Jari lost an AP in his house. * Brian: if we go too far we have to fix management * Brandon: the more the SPs blend into content providers, the more likely that the hardware in the residence is under control of the SP * Black: one of the drivers to having people deploy hardware at home is features. Homeowners add boxes to enable features not supported by their provider. ------------------ ------------------ Technical Session 2: The role and rule of middleboxes: intro and discussion (14:15 - 15:30) ------------------ ------------------ Benoit's slides --- - describes the plan for a classification project / middlebox traceroute mechanisms * Lars: Such a study was done and indicated that the behavior is unstable enough that such a study is infeasible. Home gateways have different behavior on different ports, and on the same port over time. * Miroslav: his study saw the same * Benoit: Yes difficult, but trying to classify. Maybe reliability isn't required. * Brandon: Needs a broad distribution across client space. * Benoit: No plan for that yet. * Spencer: Same concern as Lars. What can help guide identifying the range? Which types might be more predictable and which less? * Bob: Don't look for behaviors, look at vendor brochures if you want to see the range of what boxes claim to do * Brian/Mirja: Maybe do a session on this tomorrow. Some discussion of discussion scope. * Bob: Recommends the referenced Honda paper. * Brian: Despite problem in reliability, can we define the problem in a way that makes it tractible. Maybe focus on what doesn't get changed or cause trouble. * Aaron F: would be useful if "happy eyeballs" protocols tracked failures report so it can be collected and reported out (with appropriate privatization of data). We need more data on how often things are done in practice. Stack vendors and browser vendors could do this. Agreeing on methodologies and data would give some commonality and make it easier to compare. * Dan: no way to reliably categorize since different per vendor and behave different when say under attack vs not, etc. Also 0.2% globally may be 100% in some location like Switzerland. Middleboxes do lots of things, with dynamic behaviors even for a single connection. On board with happy eyeballs. * Aaron F: Maybe happy eyeballs should report unhappiness to server. Summary: observing data on what you normally do. Testing per se may not be reliable but stats on how things actually work is useful. * David B: three pieces : a) taxonomy of what boxes do, b) how to do runtime detection, c) survey of what's deployed. * Christian: Such classification has failed in the past. * Martin: RFC3489 ... the classification in the spec was a failure ... too limited. Example of how classification is difficult. * Costin: NATs are the simplest. If they are trouble, then other are even worse. Who is the classification targeted at. * Christian: Gave example of behavior you can't learn from reading docs. * Eliot: +1 for identifying the purpose of the taxonomy. Thinks it should focus on how to make stuff work. * Mirja: Purpose is to identify known behaviors and to call out ones that should not be done. * Jana: Taxonomy's value is time limited. * Erik: What Dan said indicates that the tracing model will be very unreliable. Maybe it's doable just to come up with a way to find MBs in the path. * Christian: Maybe classify according to purpose instead of observed behavior. Maybe useful to have a "bug database" of "this app doesn't work through that middlebox". May also be useful to look at what functions middleboxes do that could be moved to end systems. * Phillip: Classification makes sense, even if we don't know what data will be useful for. * Mirja: Would it be useful to have a document that says what things are good and bad for middleboxes to do? * Bob: Classification is useful to impose requirements on hardware for purchasers but not possible to get agreement on anything if all constituencies represented so doc would be empty. * Ted: Where something is in the path tells you something about who is acting. MB could lie with it's behavior, but knowing something is being done can still be helpful. Ability to drive MB behavior based on classification will be very difficult. any api about middlebox or path behavior would necessarily have to be far simpler than what they actually do. And trusting it may be an issue. * Costin: MB is usually in the first AS hop, at least the ones we care about. * Erik: Do we have data to substantiate the "first hop AS" claim? It might only be true in specific parts of the world. Also, re: location, maybe only useful to identify who's domain of control. * Brian: Referenced a paper about ECN that indicated that most of the time it was broken due to server side MB, not usually in the middle. Ted's slides (move to NFV) --- - service chaining where middlebox functions move to virtualized service functions that can scale out. - May cause variability. - Need to decide whether VFs can be part of the host stack, whether use ECN, etc. - VFs might be updated more frequently (good) but might start doing (bad) things one wouldn't do if you had to deploy a hardware box. * Bob: In general, the point of NFV is to give flexibility in management, so it should usually give good results rather than bad. * David: Network function already splitting out to client and client function already being split out to network. Hope that we don't have to relearn lessons from ECN. * Erik: Asked about which queues Ted was describing. * Ted: NFV may add hardware Q or software Q or both. * Erik: Some network functions are packet oriented and some are connection oriented. Connection oriented may add more delay. * Ted: Signaling about this could be useful. * Jana: Already flow handling on MBs in the cloud are shifting flows between queues. Is there more we might want to do to stabilize? * Ted: Such a use case may want to know more about the flow than just the path (e.g. trust domains for all the actors). This is probably session management rather than flow. Also, service chaining happens in multiple trust domains. Important for path characterization but difficult due to lack of signaling, whenever you have encrypted traffic. E.g. middlebox claims to transcode but needs to decrypt and reencrypt to do so, endpoint should decide whether it wants to allow based on trust domain. *Lars: Doesn't want to see network function get split to the client. We've been trying to move SPs in the other direction. * Ted: Yes there are downsides, but there are also positive elements of this. * Bob: There are already vendors doing this, though. Gave some examples. * Aaron: taxonomy needs to include endhost virtual middleboxes Szilveszter's slides (mobile broadband) --- - middlebox layer between IP and transport protocol, for flow identification and flow start/stop signaling * Lars: how many bytes would you sacrifice and add to every packet? Concerns about impact on MSS due to overhead. * Dan: Ongoing efforts with little uptake so far to allow network to give feedback on path characteristics to clients. - if we solved middlebox roles of "Policy Decision Point", "providing info about path" and "sending advisory msgs to apps" that would be sufficient (leaving out transport protocol performance enhancement, and app layer optimization). * Christian: How many such boxes on the path? And how to handle trust? what if path has multiple of them, does information increase exponentially and is it secure? Can be easily abused for DoS attacks, like happens in MTU discovery? * Szilveszter: Around 10, maybe? And yes, needs to have trust with all. * David: Advisory msgs seem to be at layer 2. That needs to be resolved. * Jana: Also not convinced that pushing layer 2 info up to higher layers is a good idea. * Mirja: Pulling stats from the monitoring is on the list for tomorrow. So it detection of MBs. * Richard: Lets focus on monitoring actionable aspects of the path behavior. * Dan: That's a good thing about using the happy eyeballs data. * Lars: Can application providers give feedback to the user to get them to put pressure on providers? maybe need balloons from app to complain about middlebox behavior. Referenced Dave's presentation during IETF 68 about what worked/didn't, but would like quicker feedback to users. ------------------ ------------------ Technical Session 3: Unbreaking transport: lightning talks and discussion (14:15 - 15:30) ------------------ ------------------ Costin's slides (34-37) --- - middleboxes make Internet unpredictable. Design of mptcp took 5+ years b/c someone would always stand up and say "there's this middlebox that breaks that." - There used to be a clean contract, but that's not the case. Contract is now "I will get the packet there, but beyond that I may do what I wish...", I being the network. - So apps make very conservative choices to ensure things don't change in the net. They may not care about privacy, but they want stability. - Idea for Ninja tunneling (bad cop): Create a multitude of tunnels, that makes use as wide a use as possible, (UDP, TCP, etc) and stripe it across all of these channels. It can work, but can it be efficient? - In steady state, if you run MPTCP across ALL of these tunnels, the tunnel that is most efficient will get all the traffic. If UDP is rate limited, then traffic will spill over to TCP. - One can be endlessly innovative about the tunnels. Doesn't require full MPTCP, just apply the CC alg. Can spread a packet over all tunnels, drop all but the first one. - The key point: providers can't kill ALL traffic. * Brian: how do you ID the packets? * Costin: for v4, IP ID; for v6, [shrug]. * Aaron: what happens if the mb is on the server end of the connection? * Costin: don't consider that a useful application to optimize. Biggest problem is first- and second-hop provider deployments. * Miroslav: what about the efficiency? If you try a bunch of things you will be wasting resources... * Costin : in steady state it converges... * Miroslav: but in mobile devices it's too dynamic. * David Black: Most flows out there are mice, not elephants. * Miroslav: also this will not work for apps do not get access to net directly. * Mirja: OS should do it for you. * Costin: are you saying it's difficult to do in OS? * Miroslav: saying it'll drain resources in a mobile device. * Costin: no, I open multiple tunnels, use for ALL applications. * Lars: agree with Costin, try in parallel, faster ones will succeed first. Yes, it wastes resources, but this is the world we live in. Depends on how often you do the setup. * Costin: don't think energy consumption is a big deal. * Lars: you could do some sort of DHT P2P thing: exchange hints about what has happened in different parts of the network to indicate what tunnels work, what to try first. * Jana: this is "happy eyeballs" on steroids * Brian: in tunnels * Jana: curious to see what comes of it. * Aaron: have you looked at using enterprise VPN services? * Costin: don't think that's a real solution b/c of the rate limitng story. * D. Black: feels like a remote access VPN solution... - Good Cop is the constructive approach: API to talk to middleboxes - Reachability examples: Client can say "I'll let you look at the traffic, please don't touch it." * Eliot: think of Dave T's slide about incentives. You should think about the various ways to game/abuse this. * Costin: [in the example you gave] cell phone is already compromised. * D. Black: the point is that "compromise" is not the end of the attack. * Eliot: it would be useful to use Dave's list as a check. * Bob: can't see why an ISP would want to do this, as it's a lot of work that is not tied to a cash flow, doesn't give any immediate benefit. Getting something deployed by an operator requires that it be tied to a product. * Costin: what about a generic cloud-based service that apps can leverage? Provider can charge more, all apps can leverage. UNbreaking transport slides (lighting talks) --- Brian (slide 39) -"Duelling Approaches": (i) People's front for UDP (ii) TCP libration front Miraslav (slide 40) - Redoing everything in UDP will be painful. We should provide what guidance we can on how not to do things... C. Perkins (slide 41): - Ossification is a good thing. - TCP is not a research project. As long as the wire format doesn't change, we can change TCP. - Use of UDP is a good way to evolve thing. The problem is that the result is X/UDP, a second class citizen. - How about some signaling to deploy new things? David Black (slide 42): - Scars. MPLS-in-UDP: IPv6 checksum was problem number; Congestion control was another problem. - One year later the job is done. It took too much work, took too long, and the results are not directly reusable. - We need to provide more guidance. We could use some reusable designs. UDP encap ought to be easier than it is. Felipe Huici (slide 43): - It took years and years and years for features to come in. There are middleboxes everywhere, but maybe that's not the only problem. It takes way too long to get even small features into the kernel. - We need to shift development to the user level. The result: Multistack. Michael Welzl (slide 46): - Keep using happy eyeballs. Keep introducing new features. Philip Schmidt (slides 47-49): - Let applications tell the O/S what they know so that the O/S can take more responsibility - Can we use similar things to indicate network access load? - What signaling would be useful for the network to signal back to the host? Maybe shift backups to later? Bob Briscoe (slides 21, 50-53): - Figure from Honda paper, regarding amount of option stripping/dropping of unknown options: Home networks were NOT stripping unknown options (small sample size, though). Cellular was the worst. Universities, enterprises, and WiFi hot spots were blocking a good percentage ports that were not 443. - TCP Option "space" - shows how it is easy to exceed 40 bytes. - Main point of pos'n paper: extend layer X in layer X+1. - In the case described, do it inside the TCP payload. But also gives you the ability to extend IP behind a UDP. - Inner Space: option in payload. This will go through a middlebox that resegments. - A more structured way of doing HTTP2. Brian (Channelling Stuart Cheshire, slides 44/45) - You design your own transport because TCP doesn't work. - But then your own hasthe same performance issues, but since you don't want to have wasted six months, you ship your broken solution anyway. - as Brian: there are a lot of corner cases in TCP-as-deployed, lots of stuff in sysadmin literature about "why tcp sucks" There are CDNs that are pushing the IW up to 75 packets. * Jana, channeling Stuart ;-): UDP is not a !@$#@#$!$!@# transport protocol - I hate that we call UDP a "transport protocol". 8-page protocol written in 1970. It's a demux protocol, that's all. * Christian: UDP just gives IP service to application. It's just a filter. It's "raw sockets for apps". * Colin: it's viewed as a kludge... "tunnel over UDP is a second class kludge." Goal is not to get rid of UDP but to give guidance on how to do things right. * Jana: Things running atop UDP are 1st class protocols. UDP is an encap. * Christian: HTTPS is a kludge. * Miraslav: There is no single TCP that we can refer to, to be able to claim something bad about it. If we relax TCP semantics and API, then we end up with UDP. * Spencer: how much longer should we have to wait for DCCP to come back? One of the big issues of the MPLS/UDP draft was that there was no indication of loss. * Brian: haven't been very good at standardizing cong ctl protocols. * Aaron: DCCP published a bunch of those. Having TCP in the kernel has limited risk of screwing up congestion control. Not everyone has the resources of Google or Microsoft to devote to this. Permissionless innovation at this layer may lead to places we don't want to go. * Dave Thaler: (privacy) the practical limitation is that you can only support so many IP addresses in h/w. There are practical limitations. * Jana: likes the the idea of moving things up the stack. It all works. We can't stop it from happening. * Colin Perkins: the IETF is really good at standardizing congestion control, but not very good at getting them use. * Christian: I am a congestion control heretic. I do not believe that congestion control is something that should be done in the end point. I'm not a fan of putting function in the network, but if it's there I can defend users. The stability of the Internet should not depend on who implements what stack. * Bob Briscoe: but that's how the Internet works: all the users are divided up. In Felipe's position paper, the other side is to deploy stacks on middleboxes. Mostly what we want to do is remove middlebox behaviors, not add them. Adding another one won't make it any safer. * Gorry: we kept talking about transport as if it were congestion control, but there are a whole bunch of functions that need to be shared, hard if they are in user space. * Joe: why are people who write code in the kernel are more trustworthy than those who write applications? * Lars: no one would say app-writers are untrustworthy. Problem is it's easier to deploy something in app-level, if you get it wrong, consequences are bad. Same is true for encryption and cc. * Mirja: the idea is to change the bits that you feel the need to change. Maybe retain the bits you don't want to change. * Lars: pluggable CC framework in linux and BSD has a very different framework than you are talking about. It's tied to how TCP works. Don't underestimate the API difficulties * Mirja: People will implement their own stuff over UDP; with or without kernel support * Ted Hardie: I have good news: CC is not your biggest problem! WebRTC requires browser to act like a router would act. They're trying to do application appropriate resource drain so as not to step on their own earlobes. By the time you get to IP, it's not a single flow. Moreover, this will spread: WebRTC already did the hard part, other things will come along and do similar. Processing is exploding in both directions: into the network with NFV, into the app/browser. Lots of adaptive radiation in both directions. If the Internet as a ecology can't handle this level of variability, maybe something else in the network is wrong. We have to make the network resilient to it, and in the best possible case expose APIs for it... * Philipp: now I regret skipping my second slide about how to implement socket intents... didn't go into the kernel for the prototype. If you want to build a new application, it's really hard to do all the stuff. Modern browser: not sure if it's an OS or an extension of the OS, or what. * Aaron: disagree with Ted. Congestion is about protecting me from you. Christian's proposal makes my brain hurt. What is the ISP's idea of my fair share? * Jana: Just to answer this point...N/w is not the only thing to do CC, but it's certainly doing rate-limiting. Only disagree that cc is hard to do, but it needs to been done by people who know how to do it. Independent of kernel or user space. Can be done in user space. Come to ICCRG. * Aaron: If you screw up CC, I suffer. People punished are not necessarily the users of the programmers' apps. * David: we're using the term "congestion control" as a fairly wide space. At one end of the spectrum, there is are specific algorithms: CUBIC, Vegas, ... In between, we have the AIMD vs. TFRC. Some of this can be rather harmful to real networks. At the far end of the spectrum we've adopted "circuit breakers"for situations where s/t is clearly wrong and s/t needs to be done about it. These circuit breakers might be more important as we go permissionless. * Erik: following up with Ted about putting all internet functionality in the application. It is equivalent now to a router: muxing on both upper and lower i/fs. This is richer than what we talked about before. I assume, Ted, you would send different packets out different ports.. * Ted: yes, and some will go through TURN boxes, some not,... routing protocol picks the "next hop" for the message that's going to a specific destination. * Erik: so CC runs where? * Ted: Congestion control is handled differently for different output ports to the extent that different ports are in different contexts. * Erik: So if app developers can get that right, CC is easy? * Ted: These things can misbehave the way routers can misbehave. Challenge where the O/S is handling TCP and app is handling UDP, and there is this mismatch. Oddity: they are doing all this stuff, but some of it is actually going out over TCP to the web server, being controlled by a differnet part of the stack! So they may interfere. NOT trying to say CC isn't important. We've already handed ability to shape traffic at a sub-5-tuple level to the browser "stack". There is much more complexity here. Bad news: they way sandbox tabs work now is, they are a hypervisor for a set of VMs. * Eliot: "Ted, you're a hard act to follow". Go back to David's comment about the "gentlemen's agreement". CH's proposal also made my brain hurt. Question for tomorrow: where is the endpoint-network line? What work needs to be done in terms of the host, and the network? * Christian: don't get me wrong, I will try to do the right thing, but ultimately the enforcement has to be in the network. * Eliot:If we are working under the assumption that there is a gentleman's agreement where there is none, the network is a backstop to prevent that. * Lars: User space stuff is good where there isn't competition on the device. But for general purpose libraries? * Aaron: careful about separating building things atop UDP and in user space. building on top of UDP != building in User space. User space is about speed of deployment, UDP is about pervasiveness. * Joe H: Agree. Other thing user space allows is to try out some new things, without having to devote as many cycles to get to running code. But there may be efficiencies to sharing, putting in kernel. So, e.g., can start thinking of kernel as another node in the network. * Jana: agree with Aaron's distinction. What's difficult and easy to implement depends on where you work. Filter becomes what you control. User/kernel distinction kind of depends on context (e.g., mobiles it's different). Android, iOS have different ... If you want fast deployment, you need s/t outside OS. * David B.: when you move parts of stack into user space, it gets more interesting and less predictable. Sometimes it matters, sometimes it doesn't. If you want to move the whole stack, it gets really interesting when the OS is there to help mux resources under you when you didn't expect it. * Erik: (on inner space) if we have middleboxes with various DPI things (e.g., .XML => run through XML parser), moving part of the TCP header into payload will fail. * Bob: there's an option to get through one of those boxes, that puts dummy http headers.. This is not trying to get through security checks, ... * Erik: are you saying you can detect mbs on the first segment? * Bob: no, URL filters just parse as far as they need to... you need to encrypt to protect... * Jana: like inner space proposal a lot because it makes TCP the substrate. You're going to have to do work, but this gets you past some middleboxes. * Bob: Right. Designed for middlebox operators, another thing: framing of TCP payload could be offloaded to an outboard function... * Jana (channelling Stewart talking to Brian as Stewart...): here's a common application design pattern. App developers don't understand what the problem really is, and will go ahead and blame TCP without investigating. Common pattern is blame TCP, (try to) fix it in a brand new protocol, fail because you didn't really know where the problem was. We need to spend time teaching people how to use TCP. Plus writing your own thing leaves you without tools to debug. * Brian: another whole topic: how do you tool for debugging? Discussion --- * Brian: "Now we have to figure out what we just said..." * Mirja: We didn't address the service composition question [TAPS] at all. Is this something that's not interesting b/c it's already addressed by taps? or did we not have the right slides? * Joe: what's it look like to the app developer is more important than how to talk to the kernel... Maybe a subset of people can hash that out. * Brian: that seems more like the 4th TAPS deliverable after the recharter... is the expanded transport API and the path characteristics API separable? * Dave T: separable to some extent, can imagine layering them (path API lower). One-way dependency. * Gorry: separable but both really, really useful. * Dave B: +1 * Ted Hardie: in a world where these are separable, where you are talking to the path outside the transport, you rapidly make it un-useful for most application work, b/c they add too much latency. But if you get backscatter as it goes along (i.e., via unifying them) you get a significant benefit in latency - at a considerable cost in complexity. * Joe: set of events, from different layers, some in kernel, some not. Might chain in interesting ways. * Aaron: sounded like what Ted said was compatible with what Dave T said - you could stack these on top of each other. Unified transport could have two APIs at differnet levels, one on top of the other. * Ted: agree * Colin: to what extent is the path discovery a feature? Is it part of the path discovery... - Topics for the second day: (i) Inline middlebox measurement. (ii) Work to be done around guidelines, enablement, etc. for user-space stacks. How exposed to apps, how to do permissionless innovation without breaking the Internet. (iii) Path characteristics API - Think in terms of events you can send/receive: start, end session, get path char (see iv). (iv) Path characteristics protocol (SPUD?) [middlebox layer] * Joe: one possible incarnation is over UDP to get info to/from path via a separate channel. Session protocol, used to start/stop sessions that mbs could use it. (Includes failure reports in happy eyeballs.) (v) Trust domains - because the problem isn't hard enough. (vi) UDP design guides. [Note: differs from user-space stacks.] ("UDP for dummies") * Aaron: that would be a great topic for an IETF BOF. * Bob: would like to know how many people agree with Christian's point that we are not going to make any progress until we change the balance of power... COuld talk about what a working group would look like in that space... a number of hings we could look at without protocol design. * CH: many aspects: what are the roles of DTLS, TCPINC, ... * Joe H: I was thinking about that in terms of reqs. That might be a separate path. For people who don't believe UDP is the way to go, maybe talk about TPC implemetnations... * CH: if you think CC is hard, re-doing TLS is really hard...need a common layer... * Spencer: Aaron pitched a thing about a non-WG BOF. BOF request date is next Friday. * Brian: so we have time!