[Stackevo] Notes from 2015-11-03 Stackevo Program meeting

[Cindy Morgan <[e-mail]>]

IP Stack Evolution Program Meeting
3 November 2015
Yokohama, Japan

Attending:

Jari Arkko
Mary Barnes
David Black
Marc Blanchet
Spencer Dawkins
Ralph Droms
Lars Eggert
Aaron Falk
Ted Hardie
Joe Hildebrand
Mirja Kuehlewind
Cindy Morgan (scribe)
Erik Nordmark
Dave Thaler
Martin Stiemerling
Brian Trammell
Hannes Tschofenig


NEW ACTION ITEMS:

- Brian to invite Natasha Rooney to join Stackevo Program

- Ted, Joe, Brian, Aaron to organize potential CROWN [?] BOF.

- Dave to work on adding case studies to draft-thaler-transition-
  principles:
  o ECN (failure of): Brian
  o MIME: Marc
  o MPTCP: Mirja

- Dave, Jari, Hannes, Joe to work on proposal for IoT data sharing 
  workshop



1. post-MaRNEW work in the Stack Evolution program

Brian: Can we talk about what we saw and what we can pull into the Program?

Ted: I think 2 things happened that were reasonable. We got folks who were not deeply involved in radio networks better to understand the kind of radio network management needed. We got the GSMA folks to understand that what they're thinking of as SDFs isn't actually what they need to do radio resource management. What we didn't get was data. I think we were expecting to see more data about the extent of the problem they were seeing. I was expecting to see a couple of graphs. I'm not sure if it's because it's all proprietary data. They did take an action to go and get some data, and they'll take it into GSMA where it's under NDA, sanitize, and then bring it to us where we can use. I think it is proceeding as joint work still and has a hope of going forward. A bunch of the people going forward, all of this work needs to happen in 3GPP as well. At a general level define protocol mechanisms at IETF, and 3GPP tell us how it fits in.

Mary: I think you hit on what I had. Getting them on board and understanding the problem.  

Spencer: I think it seems like to me we're still having a very different conversation when we're talking about the ability to react to congestion on time scales. Our time scales are so much longer than theirs. Getting everyone to understand that we're not talking about the same time scale on stuff is going to be critical. Should be reacting to instantaneous radio conditions--would be great if you're 3 feet apart, but will be hard on an end-to-end connection.

David: Some drafts in TSVWG that assume you can do radio bandwidth management because you know the entire end to end path.

Spencer: If you've seen the 5G and IP mailing list, it's worth looking and they have some ideas. The idea that people will just deploy security protocols for electronic commerce, because we're special, and we have needs. For me there will always be that echo. This works less well the more stuff you encrypt end to end.

Mary: We should invite Natasha into the Program (ACTION FOR BRIAN)

Aaron: I think that there were some bridges built between the 2 communities but they're not very strong. The IETF privacy folks said in public they'd hide their IP addresses if they could. That may color their views on the importance of the mechanism. We need all this stuff, and when confronted with all the already encrypted traffic, they didn't have an answer--they don't know what's going on in the network. A recurring discussion on what if you had 1 bit exposed that said I'd rather have this packet queued or dropped--privacy folks didn't like that, and others didn't know. Data is needed. I am working on getting some data on HTTPS trends in global networks.

Lars: I wasn't there, but is the GSMA a body that is the right one to talk to?

Joe: It's one, but not the only.

Lars: I am wondering if 3GPP might be the better body. I doubt we'd get the technical stuff out of GSMA

Mirja: The privacy thing?

Aaron: I don't think he was representing a large community, but they are vocal.

Mirja: Ratio of people?

Aaron: 1/3 IETF, 1/3 wireless folks, 1/3 other folks.

Erik: Aaron said that there were a fair number of vendors. Is there somewhere with more operators where we can get a different perspective?

Aaron: I had a sense that there are small number of people in the operator community who understand this in detail, but above that it gets very thing very quickly. But the people building the products that interact with the protocols, but they have incentives that skew their viewpoints.

Erik: If we pull people from 3GPP would we get a different mix?

Mary: GSMA would need to do a liaison to 3GPP. I have a contract to go to 3GPP now, and it is very enlightening. The service providers do have a lot of influence, and if the regulators say you can't do that, then 3GPP is highly unlikely to do that. It will be a huge challenge. There is a huge gap. Man layers and levels of understanding of the problem.

Aaron: Don't need a lot of other people to bring this domain expertise in.

Brian: Just need to identify the people and make sure we can start the conversation from somewhere productive.

Spencer: My impression is they think we're the ones who are supposed to make this stuff work. GSMA is supposed to be less captured by vendors.

David: Beyond GSMA and 3GPP, what interaction do we have with the people working on NFV? I was in an OPS meeting yesterday, and realized it completely changes the characteristics of some of these carrier networks.

Mary: This gets us into the 5G stuff.

David: I've seen a lot of technical marketing material on NFV, and would like to see how much is real.

Martin: The standardized version of what people are doing is maybe 5 years ahead of the 5G folks.

Erik: In terms of the people we talked to, the key thing is not to have the policy discussion about lawful intercept. But instead say it's not up for discussion--we already see it's going on. What do you need to do, what is the operational discussion. If you start saying what about policy and what needs to be in the clear, I think this will go nowhere.

Ted: I do note that at the meeting I made a joke about a BOF called crown, and many people didn't take it as a joke and want to have one that looks at standardizing something like what we're experimenting with in SPUD. They want something in their network soon to decorate their flows. Huawei, Alcatel. The idea is the [] does the decoration. If we don't take on the work relatively soon, something will happen in the 3GPPland that will need to come back. Just waited to raise the flag that there is an urgency here that we don't typically see. If we don't have this soon, their networks will fall apart.

Mary: NFV vs 5G, NFV is already being implemented, and I'm afraid 5G will take what we have and add more to it (like with SIP). We need that crown stuff, and we have to figure out how to prioritize that traffic.

Brian: Sounds like the Program needs to be more proactive in seeing what is going on here, whether that is something like crown.

Ted: I think we should raise the issue at the joint issue with the IESG.

Aaron: I think one way to push back on this is to say we need experts who can come and have a nonWG BOF to educate the community on what the points are. And have strong chairs who will vet the experts to make sure we'll have light and not just heat.

Brian: Who wants to help organize? [Ted, Joe, Brian, Aaron]

David: BOF topic?

Joe: Feedback from the people who have the urgency.

David: Kevin Smith Vodafone UK--bring him in early




2. draft-trammell-stackevo-explicit-coop
     - relationship to SPUD: is this the right scope for the doc? (see Mirja's message)
     - next steps


Brian: I've been working on this one a bit on my own. Have people read it? [some have] Do we think this is useful? Scoped right? Can we ask the IAB to accept this as an IAB doc?

Mirja: It is not clear to me what the split is in the docs that we split. I think we can streamline the doc a lot, and I'd rather we have a shot clear statement about what w want to do with the middleboxes. It's a bit hidden in the text at the moment.

Aaron: The ones who are enthusiastic about this, I think the original intentions we're emphasized, the trust domains and how to manage that. I think if you can make some clear statements to move the ball forward, will be helpful. And I don't think has been discussed in TSV yet. Get it on a WG agenda and get some review?

Brian: Which group? [TSVAREA]

Brian: Cut it down, make a clear statement of what we want, and explore and delineate the kinds of cross-relationships. 

Aaron: Track for this? IAB-stream?

Brian: That was the weak intention.

Joe: This is a fundamental architectural principle that is controversial, so I think IAB.

Brian: Who would like to help me hold the pen on that? []

Mirja: I think the trust point is important, but do we want to actually make a recommendation?

Brian: Yes, how can I make some of this stuff work.

Ted: Put a recommendation in and get community review. We might get beaten up, but then we'd have a concrete proposal to work against.

Brian: Something else came up in TSVWG yesterday. The observation is there are a couple of different proposals for using magic numbers in UDP headers for saying to treat these differently. There is a way to say if we keep this set of bit patterns, no new UDP protocols will use these, so we're less likely to see deployment.

Lars: We can't enforce that.

Brian: But you can make it difficult to have a large scale reflection attack.

David: While we're talking about this, WEBRTC is doing it. I think from a running code perspective, there is a very strong start here. I think the problem we should be solving is there is now some mush in the stack. Can we put a magic number in there so a middlebox can do what we want.

Spencer: My thing was that this is optimizing for the more you can tell about a UDP packet just by looking at it in a middlebox. 

Joe: There were a couple of things in that design that weren't obvious. 1, to minimize the number of bits involved. The proof of implementation, there is no amount of magic numbers  that will give you proof of implementation. Trying to get off the fast path as quick as possible,and have proof of implementation inside SPUD. Talk to the web server and it has to do a hash with the thing that is inside the spec, and if you go though that and are speaking websockets. The middleboxes can look at if they really want to know.

Lars: I think you can go right ahead and do this, but the only thing we need to be clear on is other applications can put the same bits in accidentally, and you need to be able to deal with that.

Joe: Right, right. If another protocol comes along that hits those bits, that traffic will end up being slower. 

Lars: You're penalizing; it's not them that are doing it.

Brian: I'll go look at a bunch of UDP payload distributions.

David: If you want a strong ensurer of uniqueness, 128 bits.

Mirja: We had the point yesterday, the [] layer. If you want to talk to a middlebox, I hope the number would be really small. 

Erik: What Tom was talking about was more than just one application. Here is a piece of information, and you need a registry for that protocol field. Was trying to do something that requires the IETF to so something.

Brian: I am hearing this is an interesting thing we want to track and think about design considerations for magic numbers. Is that program work or something in TSV?

Mirja: Put it in the draft?

Joe: Put it in, say this is one, and maybe there are others.

Lars: Have you talked to the media people? They might not be so happy.

Joe: This is the tradeoff space.

Brian: I will take this as now as something to think about, but still not clear if this is stackevo or tsvwg.

Lars: In my mind it's an IETF thing.

Joe: Getting off the fast path, proof of implementation being a separate issue.


3. Moving draft-thaler-transition-principles forward
     - do we believe this draft is ready to ask the IAB to adopt?
     - are there other general architectural principles missing here?

Dave: http://tools.ietf.org/group/iab/trac/ticket/380

Dave: It's a pretty short doc, the only feedback from Brian Carpenter, and I agree with his comments. The last sentence is meatier: "I'm thinking that this document needs some case studies; most of the meat in RFC 6709 came from the case studies." This is true for 5218 as well. Given that, what would be some good case studies to look at. There are transitions to deploy a new protocol, and transitions to deploy changes to a protocol. Having case studies, something that is an extension like DNSSEC. 

Joe: HTTP2 

Dave: In 5218, we said we were only taking things 10 years old because there was stuff to take about them.

Brian: I'd argue against using v6, unless we break it up into its constituent pieces.

Erik: It sounds like we're looking the smallish pieces that are easy to describe and not too entertained.

Dave: And things that were successful.

Brian: ECN. The failure of the ECN.

Marc: MIME.

Dave: A set of case studies should also be out of different areas.

Mirja: MPTCP.

Joe: One thing we learned in the XMPP transition was that adding an extra bit that successful deployments successfully deployed. 

Dave: And anyone who can volunteer technical details would be helpful.

Ted: Do we always want to look at transitions from one IETF protocol to another, or ones from proprietary? One that might be interesting is []. I will check on that. It was a successful transition, but the predecessor was all different projects.

Brian: I am not a mail geek, but the non-transition of the fact that a lot of the complexity in 821 was designed to operate with older mail system and are now kind of--and the YAM WG didn't remove that because there is still running code. Not just the transition towards something, but the transition away from something. 

Dave: Things that taper off, even if it's a long taper.

Joe: And ignoring what you don't understand as being a key component.

Dave: A highlight from 6709.




4. Completing draft-iab-filtering-considerations
     - IAB comment period ends before Yokohama. Any further discussion?

[not discussed]

5. stack-level and application-level interoperability in the IoT space
     - what can we do in the context of stack evolution here
     - next steps on IoT workshop

Brian: We were updating our webpage, and Ralph and Erik raised an issue that there is a lot going on in the IOT space putting things together in new and not always compatible ways.

Brian: Interoperability problem with the stack put together in mutually incompatible ways, and even if you can get the layers together they can't talk to each other. Is this a stack evolution issue? Why is this application layer model thing any different? We also want to talk about organizing a workshop.

Ralph: One more point, the parallel development stuff. IEE 802 has a PAR to take on a bunch of stuff that looks like 6tisch and 6lo. 

Aaron: Is internetworking these technologies relevant to stack evolution?

Brian: Or is there some guidance we can exert in this space? Is there help we can give so that we don't end up in a non-interoperable place. Are there nudges that can exert disaster.

Dave; I don't think the data schema interoperability--if it's not in the program I don't care either way. But it needs to be done.  We're talking about the higher level, the abstraction. How many ways to describe what a thermostat is. A bunch of SDOs overlap, a bunch of vendors overlap. Right now there is no alignment in the industry. Some don't care what SDOs do because they think they're too slow. But the world will be better if there is alignment. How can we get people to work together more? I think the proposal, semantic interoperability--

Ralph: The workshop is one meta level up looking at process for generating, not actually generating that data schema?

Dave: Not sure processing is the right word, but yet. If you look at when HOMENET was chartered, it said who they'd be working with, and they didn't work with them. And if we have this workshop, how can we get the people who are relevant to show up? If that's the people who come, we have not solved the problem. When the IAB talked about it, we said co-locating at an even non-IETF people would be at would be critical. T2TRG on Sunday went through a list of events that people in the industry might be going to.

Aaron: Why do we care how you describe a thermostat?

Dave: Because it's an architecture. We can provide advice to other organizations as part of our liaison role.

Dave: For some organizations there is an incentive. They do want to coordinate, IPSO and OMA is the same people doing worth in both organizations. Else wise, we have fingers in a significant number of these, at least half. But some of those people are disinclned to travel.

David: Overall goal is laudable.

Erik: This is not the whole list. Someone at Cisco looked at this a while ago and said it's vertical. I don't know to what extent it's changed?

Ralph: A few organizations trying to cover multiple verticals. I don't think there are many trying to come up with a general process. 

Erik: The thermostat example, they're all temperature.

Hannes: We do not want to get an agreement on how thermostats should be designed, but to come up with language so as a design pattern there are ways to describe new options. That is what some o those organizations are doing. That is what they are trying to do in IPSO. How can we make sure we understand what is going on? We thought it would be a good idea, have an independent player who has a wider perspective to open a workshop.

Dave: The sharing of information is a possibly tractable sharing like issue. We'd like to do a schema for a particular object. Do we reinvent the wheel? If not, how do you know where to look? Do you know whether ZigBee has a schema for thermostats? How do you even know who to talk to.

Aaron: A lot of this reminds me of the SIP days. Aspects of doing open interoperability that I think SIP really helped with. It seems like a large number of topic areas beyond the data schema. When you focus narrowly, you don't think about those things. But it's not clear that the value will be as obvious to the people with the startup stars in their eyes.

Dave: If the set of organizations that might be interested in data sharing are not able to travel to something they'd normally travel to, how do we incentive them to participate? Or would we need remote participation in order to get the right parties?

Brian: Next steps? 

Dave: We'll put this on the agenda for the next IAB meeting. The IAB was interested in the idea. What and when is the appropriate place to have the workshop?

Aaron: This is interesting, but I'm not sure if in scope for stackevo?

Brian: Yes, take it to the full IAB.

Dave: Let's see if those of us potentially on the PC have a side meeting. [Joe interested in participating in such a meeting.]

Aaron: And there is a possible plenary talk in here as well.