[Stackevo] Notes from 2018-07-17 IP Stack Evolution Program Meeting, Montreal

[Cindy Morgan <[e-mail]>]

IP Stack Evolution Program
Tue 2018-07-17
Montreal

Attending:

- Jari Arkko
- Brian Trammell
- Gabriel Montenegro
- Erik Nordmark
- Martin Thomson
- Spencer Dawkins (remote)
- Aaron Falk
- Mirja Kuehlewind
- Tommy Pauly
- Dave Thaler
- Cindy Morgan (scribe)

1. Using URIs With Multiple Transport Stacks

Dave: Back at IETF 99, in the ARTAREA meeting, I presented an individual submission, draft-thaler-appsawg-multi-transport-uris. It's about URI scheme and URI design, when there are multiple possible paths to the bottom. One thing at the top, might be two things below that, could be things about HTTP and BGP. Stacks and trees. When doing URI design for things at the top level, to what extent does it ecocide things below that. CORE WG asked for permanent registrations (coap+tcp, coaps+tcp, coap+ws, coaps+ws). OPC asked for something similar.

Aaron: Any relationship between these protocols?

Dave: Only in that they might both be called IOT. There is lots of debate about how to expose the same resource over multiple transport stacks. There is a doc that its the architecture of WWW, argues to minimize a set of cases. Ideally only one URI per resource. The more you have, the lower the value. The notion of secure vs insecure, it's good to have that so you can tell the security level by looking at the URI. 

Dave: RFC 3986 similarly argues for minimizing but doesn't disallow it.

Dave: RFC 7595 gives list of requirements for permanent schemes, but this topic isn't one of them. The state today is that it's argued on a case by case basis. 

Aaron: Sounds like the arguments are on the weak side.

Spencer: This is what we'd do if it was us, basically.

Dave: A lot of heterogeneity out there.  The doc I wrote surveys a bunch of things that happened and what the issues are. Plenty of other examples. The question I asked is if it should be AD sponsored.  Barry Leiba asked if it should be Informational or BCP. Get feedback on the ART list. The most interesting parts of the discussion, it's a source of  disagreement even among the best experts in the TAG. Perhaps it would be better to record a briefer note that there was some history of difficulty in reaching consensus on the connection between URI schemes. Adam Roach asked if we are likely to get consensus on any actual recommendations. 

Brian: Could probably get consensus to keep doing what we're doing.

Dave: If it is not likely to get IETF consensus, could it get IAB consensus (likely in Stackevo)? If neither, do we give up and go away like the TAG did?

Spencer: Looking at the current membership of the TAG, the only name I recognize from the discussion is Tim Berners-Lee. Could you get the completely different TAG membership to get consensus now?

Dave: My personal opinion is that that's not the right place to do that even if we could. URIs have a wider applicability than just the web context, and the W3C would only focus on the web context. The IETF has a wider domain of usability for WGs.

Aaron: I am a little confused. The substantive point for the recommendations that were contemplated were about search, which is very much about web. Is there a broader context for this?

Dave: Not just discovery, also about selection.

Aaron: Selection may be very interested in the lower layers of the stack.

Dave: How do I get the possibilities? Name resolution protocol, within the URI. Where is the port number specified? A set of URIs, one per transport stack, etc. It's not about URI schemes, that's just what I picked as an example.

Aaron: This is very related to what's going on with TAPS. Notion of preferences and what works and as soon as you put in the URI, you lose all of that.

Tommy: Discovery is different from constraining to different things.

Aaron: The IETF has an interest in seeing some good things, in a direction that doesn't prevent the evolution of that kind of flexibility. That leans me towards the IETF should do something.

Dave: But do we think we would be able to consensus?

Martin: A lot of it goes back to what these things are for. COAP had a very different perception of how these streams are used. This was the disconnect of the TAG understanding and what was going on here, and HTTP lessons don't necessarily apply in COAP because there are different expectations. 

Aaron: Does DTN come up? They are a user of this. I think they use the URIs to determine a bunch of stuff.

Dave: May be more informative references inside a category.

Martin: Interesting because it's kind of the lynchpin of discovery HTTP is based on. I suspect it will depend a lot on the context, and if we talk a lot about how these are for humans, transport is HTTP, maybe it's a thing for SIP. We are still struggling with the S in HTTPS. If you have a not secure option and you want to introduce a secure option--

Brian: And it took a long time for ALPN to work as well as it does. HTTPQ is dead, right?

Martin: Some people don't think it is.

Brian: To Dave's questions, are we likely to get IETF consensus on a useful recommendation? No. On a useless recommendation? Maybe. Could we get IAB consensus? Probably. Would IAB consensus be useful? Unknown. HTTP-whatever...example of a widely successful standard. Most of the people who have extended them successfully have done so without knowing what they were doing. In many cases we didn't build an API that allowed a specific end point to talk to a specific protocol, and URIs are what people clamped on to. And I don't really want to call them URIs because they don't have all the strings URIs are supposed to have. Usually these are becoming things technologists have to deal with, not the end users. We have the problem, the narrower space where we try to figure out how to specifically do connectivity between 2 stacks. In TAPS we're trying to do it automatically but we're not there yet. That is a completely separate way of doing this.

Aaron: In TAPS it's not automatic but that you're taking preferences in from the host system.

Tommy: How do you map those.

Brian: Might want HTTPSM where you we're willing to deal with multipath connectivity. The end of the rambling here is that I think the problem we are trying to solve is bigger and hairier than Dave has outlined. I think the IAB could maybe do a considerations doc.

Spencer: It seems like the IESGs I have served on have taken IAB considerations seriously. The other thing is when we have an architectural conversation like this that we don't have architectural recommendations for, we take the recommendations one document at a time on the telechat. If you all have the opportunity for one considerations doc, to me that seems worth doing.

Tommy: ALPN is a good example of how this can work because it allows more flexibility and options in ways the URIs do not. With regards to TAPS architecture, we added a section there on protocol stack equivalence, what are the things that are available to be swapped. In the case of HTTPS, we have an equivalence between HTTP2, TLS, and HTTP over QUIC, and so presumably those are safely swappable. If we have a more abstract view of the protocols, the considerations feel like they should also have a notion of whether they are equivalent or isomorphic. The security equivalence is a lot trickier to nail down. It would be great if we could get to the point where the recommendation for the URI protocol defines anything that is isomorphic to X, and then use things like ALPN to specify. HTTPS via happy accident can be used as a scheme that defines, get the same security properties, and we think those are safely isomorphic and we can move between. They are only truly isomorphic if you use the same properties for all of them. Would be great to see other URIs follow that same model.

Mirja: In case of COAP, COAP plus TCP or COAP plus web socket is a different protocol.

Tommy: The application running on top needs to be aware.

Brian: Same interface up, same interface down isomorphic.

Tommy: Presumably the URI comes from above the application, so if you had a COAP ALPN--

Mirja: I think there might be a couple of underlaying problems where people don't have a mechanism for discovery. I don't think just making a recommendation helps. 

Brian: Recommendations for discovery is definitely IETF not IAB.

Erik: Trying to figure out the scope of the problem. It I can talk to the end point and do ALPN, what happens with happy eyeballs, figure out which ideas will work, keep all of the lower layer stuff out of scope.

Dave: How do I numerate the things that are possible.

Tommy: Address at the IP addressing layer. 

Martin: You'd have a .ipv6 on the end of the domain name.

Tommy: Put 4, 6, or * in every scheme. 

Erik: I don't know how common the SLP records are, I know they are used for SIP. But in terms of what we can accomplish, I don't know if we have WGS, having less choices and a smoother path.

Brian: Taking the doc and saying "don't invent anything new."

Gabriel: I think you could get IAB consensus on the existing doc fairly quickly, but it would be a good to say what Dave says from the IAB. I think there is value there. But I believe you also make some recommendation, and we should look into them for discovery. You can find the information and have prior knowledge, we knew that. If you have prior knowledge something works, you need to give na indication. There are ways to do that by negotiating. We want to eliminate that, but if you can give a hint how the optimization works. If the recommendation goes toward having people consider a clean architectural approach, here is the way to discover the routing to that end point, that would allow much better selection. We might be able to move the needle a little bit.

Martin: I think there is something here to be done and value in having someone say them. But we (as a recommendation body) don't know what these are for, and I think that's the weakest point. We make assumptions. We have a bunch of constraints that we can put on the problem, which is that the URI is, for the purpose of establishing protocol []. Beyond that there is a wide a array of things we use them for so it may be impossible to get a comprehensive set of recommendations, but we can say if the following set of criteria are met, we have this recommendation for you, or if these other criteria are met we don't have a recommendation for you. The taxonomy is interesting enough that knowing what the space will look like would better allow us to address those recommendations. A couple of key points of usage in that space that we understand pretty well. I suspect that we might end up saying "don't do SIP" as in don't do what they did. There are some great object lessons to be taken there. 

Dave: Do not assume that HTTP is the top of the stack. There are other possible stacks, HTTP is not the thing the application. More likely there is a URN that DTN resolves. But DTN and OCF are all at a higher layer. Another valid use of URIs at the top of a stack.

Brian; Might be the same string and mean different things.

Dave: When I did the doc, I came away depressed thinking we'd never get IETF consensus on this, but whether there is IAB consensus possible, I don't know. Willing to try, but whether it's useful consensus. There is a sentence in the abstract that says here are some considerations. Alexey is the AD-sponsor, and Adam requested that sentence be removed so that it doesn't take URI scheme designers are the audience, because he thought it was better as a problem statement. We can get IETF consensus on and Informational doc of things to think about. Could we get a BCP? Not sure.

Mirja; Do you think tunneling is part of the problem?

Dave: Yes, there is a problem, but once you have tunnels in tunnels, top to bottom can be pretty long. Is it part of the problem? It's a problem, but I'm not sure it's the same problem.

Aaron: I think there are 2 audiences, one of people who are developing URI schemes, and other is people building things under those URI schemes. You can do some conditional statements to the implementers. If the following things exist, don't duplicate these mechanisms that exist elsewhere. Avoid sticking in lots of recommendations to specific things in your URI schemes. I think there might be a larger--this might be an IAB thing where the IAB can steer the IETF in a direction so they don't feel they have to build those things in there. Maybe we should be thinking about how to make things work.

Spencer: I got in the queue to point to things in the email thread, Carsten's thread about strategic and tactical use of URIs, and how badly do you want to use these instantly. I think that is even more interesting given the discussions we've been having in TAPS. If there was an Informational doc, I don't see why the IESG couldn't ask in the doc shepherd checklist if anyone thought of this.

Aaron: Reminiscent of the DNS character set issues. Use and abuse of URIs, try to bring up the issues, something that could come out of this. I think there is a lot of stuff that happens at the lower layers.

Brian: Things we need to fix in TAPS. One of the asymmetry things, we're actually getting pretty good at happy eyeballs for clients that reach to servers in multiple ways. But we don't really have a grip on the server side of happy eyeballs. If you can't pay enough state to avoid paying the latency--

Aaron: I think the history of the Internet is, it's just a point in the technology arc--

[Everyone speaks at ones]

Dave: I think that's a rathole.

Brian: I heard a few concrete "someone should do this." What seems would be useful to try would be to start off with a very restricted scope with pointers, that says if this case, read this, etc. Here are some specific recommendations. Considerations and practical recommendations. If we get to the end of the IAB process, there is a sweet spot between narrow scope and usefulness, and maybe can then get it to the IESG.

Martin: I think I need to give Dave a pretty thorough review of the doc, because I saw a few things that need to be addressed. 

Dave: Adam is also looking for a document shepherd.

Martin: The things I am thinking would put it more in the co-author range.

Brian: I would be happy to shepherd this in February 2019; won't have a lot of cycles for this until January.

Dave: It's gone through ARTAREA review which included W3C folks, and been discussed at an IETF meeting. There is nothing to do on this until we're ready to discuss.

Brian: If you think it will be ready before Bangkok, you'd want a different shepherd.

Martin: Might need to put a stake in the ground.

Brian: Does anyone thing this shouldn't be in Stackevo? [No]

Aaron: Should be careful about basing this on the TAPS stuff since that's still more in the research phase. 

Tommy: TAPS is a use of this. I think you can point to--

Martin: Let us not pretend for any moment that URIs are well-designed. 

Tommy: Point to things like QUIC as why you wouldn't want to encode.

Aaron: I like examining the counterpoint, the SIP example. It's good to look at things we did that were not successful. Do you think we could have someone who was involved in that for our next breakfast in Bangkok?

Martin: Maybe Jon Peterson by phone?

Brian: I won't be in Bangkok, volunteer to chair?

Aaron: I can chair.

2. draft-trammell-wire-image, draft-hardie-path-signals, draft-thomson-use-it-or-lose-it 

Brian: Would like to check progress status on docs we sent up to the IAB. I haven't seen anything on the wire-image doc, it's still draft-trammell not draft-iab.

Martin: It's short, concise, and needs review.

Aaron: Have you sent it to PANRG? 

Spencer: Long term viability of transport mechanisms, these are relevant to transport area and areas that care about transport. Is that stuff that needs to happen in stackevo, is that stuff stackevo members need to be more helpful on?

Brian: They are technically with the IAB, but please Program members, comment on them. I think we should probably send all 3 up together. 

Aaron: When were these last revved?

Martin: Not changed much since the last IETF. 

Brian: Please take a look at use it or lose it before Bangkok. I think draft-hardie-path-signals is potentially more controversial. If you are removing information from a protocol you need to consider how to deal with that.

Mirja: If you expose information to the path you should explicitly design it to do so.

Martin: Decide what you want to tell the path, and keep your stuff and their stuff separate. 

Brian: draft-hardie-path-signals needs eyeballs. I think the task is on the IAB is to get it on an agenda to say we'll have a discussion, draft-hardie-path-signals and draft-trammell-wire-image ready for community review by the end of the summer. If Cindy can put it on the IAB telechat for September 5 to decide if it is ready for external review. draft-thomson-use-it-or-lose-it I think can follow those 2.


3. Collecting Architectural Recommendations

Aaron: Seems there is body of architectural recommendations docs that have come out, a lot of good ideas spread out over time. Is there a page one can go to see all of the considerations?

Brian: Would you like a bound copy of the Internet architecture?

Aaron: My fear is about these things fading from memory, docs having good information no one remembers. Maybe we should have an architectural information page.

Brian: I had thought about this because I'd thought about putting together a two-lecture course on the this, and I think what you're talking about would be the reading list. We have on the IAB and IESG talked about how to make it easy for people to jump in and understand what's going on. We used to have Dave Thaler on the IAB as an internal institutional memory.

Aaron: Sally Floyd used to have a page that did something like that. 

4. Other Business

Spencer: I sent a note to the list about how we do network operations. 

Brian: There is something that may come up in PrivSec, a privacy considerations section research project that's trying to get spun up. I have told them that they need to be pretty careful about talking to people in the IETF who have engaged themselves on this topic. I can hook them with you, because it intersects a lot--they are specifically looking at cyber security defense, the enterprise defense problem. 

Spencer: This feels somewhere like architecture work. There was also a talk in ANRW on TCP congestion signatures, Jana talking to the authors about if you can have end points that can tell the difference between self congestion and external congestions. Wonder if we need to be headed off to the land of end point and bottlenecks. But I think we have a better story than that.

Mirja: I think that's in the scope of TAPS.