[Stackevo] Notes from 2017-07-18 Stackevo Meeting

[Cindy Morgan <[e-mail]>]

IP Stack Evolution Program Meeting
18 July 2017
Prague

Attending:

Jari Arkko
Spencer Dawkins
Aaron Falk
Lee Howard
Suresh Krishnan
Mirja Kuehlewind
Gabriel Montenegro
Cindy Morgan (scribe)
Erik Nordmark
Mark Nottingham
Thomas Pauly
Natasha Rooney
Jeff Tantsura
Dave Thaler
Martin Thomson
Brian Trammell


AGENDA
-------------

1. MaRNEW: what now?
2. On Endpoints
3. Access Network Terminology.


NOTES
-------------

-- Agenda bash

Brian: When the Program started, we didn't have QUIC. We now have TAPS. Two new drafts on our agenda, one of which is definitely stackevo, and one which may just be an IAB draft that stackevo should take a look at. We had a paper at ANRW on TFO, the numbers on which directly contradict the only other numbers on that. We on purpose picked the cleanest network server we could find. A lot of focus on this may be on the access network. 

Gabriel: We put TFO back in Windows back in April. I don't have numbers, but there's been some usage.

Martin: We were having a discussion about this, and it's a mess. The observation that 20% is failing has helped.

Brian: There's Google and one Spanish insurance company doing this, and the Spanish insurance company is doing it wrong. That becomes a more interesting study--it's a different failure case then we've seen. ECN is a default server side deployment. Will be interesting to see if TFO just gets overtaken.

Brian: So, path signals. I think that's still a Program document. Should be added to the agenda of a call so we can find a way to transfer some of the state on that out of Ted. It may be that the Program is done with it.

Martin: I thought that was the point of PANRG.

Mirja: I think it might be a good IRTF doc.

Brian: The little statement of principles, we could put on a website and then take the doc and send it over to PANRG. That sounds like a pretty good plan. The detail we want to put in that doc is right in the middle of PANRG's charter.

Mirja: PANRG isn't chartered yet.

Brian: We have a year.

Mirja: But the question if there is a sufficient number of people interested to work in it.

Aaron: The path signals doc came from Ted?

Brian: Yes, it was sent out to the list a couple of times but hasn't been on the agenda yet. This was getting the principles out of PLUS.

Aaron: By sending it to the PANRG, it becomes an IRTF doc, not an IAB one? IAB docs are maybe a bit more advisory?

Brian: The plan we had to flesh out the talk was to how to decide whether something is a good idea or a bad idea; we're going to put a bit in the IP header that can be changed if there is congestion without a drop. Figuring out where the neutral zone is there. 

Mirja: We already have something that are path signals and we should be explicit about that.

Martin: And we should stop doing it accidentally.

Brian: Ted says we should do it explicitly, which is complementary to that point.

Aaron: Probably the two things to think about whether the consensus should come from the IAB. Maybe a bigger doc from the RG and a shorter doc from the IAB with recommendations. 

Brian: So it starts out on "Signal Type Inferred" and the options. These need to be expanded, and that seems like work that fits into PANRG. And if the Intro is those three paragraphs, we can talk about the IAB making it a statement. Sections 3-4 need to be fleshed out. Those of you who haven't read draft-hardie-path-signals should take a look at this. We'll start a thread on this on the list. Split it in half and send some of it to PANRG. The Program can also make statements, but I think it would be a bit stronger coming from the IAB. I think in the whole IAB we've been having the discussion long enough we can do this.

Mirja: I can talk about 3GPP.

Natasha: 3GPP liaisons sent to NGP group at ETSI which I can't share, but they thanked them for their original liaison. Due to the short time frame 5G in ETSI. Not feasible for 3GPP to consider new protocols. ETSI welcome to bring company contributions to the CT WG. Effectively, thanks for playing. 3GPP would not like to coordinate communication between ETSI and IETF on this. Not interested in the work going on there.

Jeff: Having attended the meetings, they haven't produced anything else could use.

Brian: The chair of that group did send a liaison to the IAB thanking us for our input.

Natasha: Within GSMA world looking at deployment structures.

Brian: This particular flare up seems to be dying down.

Jeff: But it would be good to establish a relationship with ETSI; no point in ignoring. Maybe can use NGP.

-- MaREW: What Now?

  The program will continue to follow up on the results of the Stack 
  Evolution in a Middleboxed Internet (SEMI, Zurich, January 2015) and 
  Managing Radio Networks in an Encrypted World (MaRNEW, Atlanta, 
  September 2015) workshops, to negotiate the tussle between privacy 
  through ubiquitous confidentiality and opportunistic encryption, and 
  the manageability of networks of all kinds.

  - Publish the workshop report: change editorial tone, update to 
    present
  - This discussion within the IETF has predictably moved into QUIC
  - Another workshop?

Brian: There were 2 major areas of comment on the workshop report. Some concern that having something with an RFC number on it that says nice things about operators was not a thing the commenters wanted to happen. And the original text was 2 years ago and written in future tense. Some of it happened, some didn't, and some is OBE. Need to make sure the tenses are correct and figure out what we need to do to follow up to make Spencer happy.

Spencer: The workshop report is what happened in the workshop. 

Erik: But we can put in references to things that have happened since.

Martin: The point is to capture what was said at the workshop. The fact that the date is 2017 doesn't change what happened. If someone can generate the paragraph, we're done.

Natasha: There may be some places where it's not written in the IETF style, but...

Brian: Formatting isn't an issue, and I think one of the comments on tone can be ignored. And there are things we can footnote.

Aaron: And maybe an appendix with updates since the workshop.

Brian: Maybe replace section 8 with that. I talked to Natasha on Sunday, there was a miscommunication on who held the ball on this. Getting a second editor would be helpful.

Spencer: I can do that.

Brian: And if Natasha can take the latest thing and push it to GitHub. And I'll take an action to schedule a midterm call on this now before our calendars fill up.

Lee: What about another workshop?

Brian: We don't have any way to actually see data on how much of what kind of classification is happening or not happening and having impacts, so it's difficult to make engineering inputs to the IETF on that.

Erik: More docs on the encryption, but have been on radio management. Is there something we can do to shine more light on that, gaps? I know Natasha was trying to get data and people couldn't share. But raise awareness and if you have data.

Natasha: GSMA will publish a report on this soon. It will be based on 4G technology and things will change.

Mirja: I am one of the authors of the manageability statement in QUIC. All sorts of smaller companies that don't come to the IETF, and that's the input we'd need. Maybe a workshop would be the way to talk to them.

Aaron: People who don't come to the IETF won't come to the workshop.

Lee: Difference between a one day workshop and an IETF.

Mirja: They don't have a good understanding of what will be encrypted.

Brian: There are people we've talked to who think it will just work.

Mirja: They're aware of QUIC but they're not worried about it because they don't know when it's coming.

Brian: The one vendor I talked to about this was, they're giving us an out so we're going to take the out. This is why I get up in QUIC and say this is dangerous

Mirja: If they have a customer who wants to monitor it and they can't, then they block.

Brian: This is more the mm encrypt middlebox stuff.

Aaron: 3GPP lunch meeting today on the official agenda.

Brian: Traffic classification will be way down in the weeds for this. For me on the RAN thing, I was disappointed in the lack of info from the operator community, and we need to look at traffic to assign stuff to different bearers, but we don't and move on.

Natasha: 5G will be different.

[Groans/laughter]

Suresh: It's difficult for them to agree to share stuff. 

Aaron: They want something from us so there is an incentive. 

Brian: Beyond that, there will be a one bit report, looking at this in various space. AQM is continuing, research on it in 4G and 5G networks. Anything for us to do on that other than monitor it? It's hard to say on the 5G side because it's not done yet. Do we need to influence the requirements so they're not stupid?

Spencer: We can ask, but release 15 is going to happen and anything the IETF does is more likely to slow it down than help it happen.

Erik: Are the people looking at this from the 5G perspective thinking it will be encrypted?

Natasha: They think it will be encrypted and just work.

Erik: If they're already figuring out the software, then we're done.

Jari: I think we're being too tactical now. There is more ability in the network to do stuff. The future networks have more ability to do stuff. Is there more we can do with application network working together. It's not release 15 or 16, it's a long term stress point for the internet. 

Erik: Is that PANRG or do we need to raise awareness sooner?

Brian: PANRG is explicitly not touching that. One of the problems we've had in transport is looking at the network in terms of link characteristics. All I know about that is what I get from 2 layers below me. We have a whole lot of experience with that not leading to good outcomes. The big question on the TSVAREA list is that it looks like cross-layer optimization, and we're more interested in what you can do when you get control over multipath on the other box. It's a different thing from the way we've looked at this in the past. How can we corroborate from that first hop from the IP standpoint. 

Jari: If it is architected right and many other conditions, that would be a useful thing to have. 

Brian: Are you coming to PANRG? Can you make a related comment about that at the mic?

Jari: [Has a conflict in that session]

Gabriel: There may be another angle on less explicit cooperation. They're aware it will be encrypted, that sort of motivation about not doing optimizations that are specific to things.

Brian: The 0 bit option in ACCORD. And we don't need to do anything to make that work happen. The ideal situation for us is when the link we can model from that first hop just sort of works, and whatever the network needs to do to do what it needs to do--they'd be easier to engage with at the transport layer if we could come up with a set of metrics. If there is anything in band then we need to distill that down. This is a slight generalization of the discussion we've been having in QUIC, some AQMs need to function.

Jari: Those would be the sorts of things we'd find helpful. There is this information and our understanding--

Brian: Is there a 5G info workshop we can get people at--

Erik: Maybe this is more forward looking. Need to think long-term, share visions of what they think and is it useful to have a workshop. 

Brian: We can define a set of metrics and ask them to design around them. If we can get experimentation that shows 1-bit works, you can do a lot with 1-bit plus RTP.

Jari: The other thing is that this isn't just encryption. Used to be able to look at addressing a little bit. The amount of information is shrinking and what other things we can replace it with. The workshop idea is a potential repeat of the MaRNEW thing. People come in and they have opinions or wishes that don't match reality. That's a problem and I don't know how to fix that.

Brian: Pick a set we believe in, say these kinds of signals are probably okay, we can probably commit to you having it in the future.

Lee: Can let PANRG and 5G roll with that.

Jari: There is other stuff that is critical as well, when things change in the network. 

Brian: I think one of the things PANRG will talk about is how to blur the control plane data plane moat.

Aaron: I think the discussion homed in on, lacking a clear statement from the 5G community about what they need, we'll make up something we think will fit their needs.

--On Endpoints

  The diversity of “endpoints” in the Internet — applications, 
  transport-layer ports, hosts, gateways and tunnel ends — is far 
  greater than that the IP protocol stack was originally intended to 
  serve. This has impacts on protocol design, because former assumptions 
  about the properties of these endpoints may no longer hold. The 
  program is currently focusing on the stress this places on the 
  architecture.

  - draft-trammell-whats-an-endpoint
  - Other work to do here?

Dave: Is there justification for that assertion?

Brian: Was hoping you could help with that?

Dave: Actually have the opposite. An end point is a generic term that means different things to different people. Each layer has its own definition of endpoint. An application layer, an email end point. All the things you talk about, gateways and encapsulations, all existed. I think there are analogous things that existed in the early days and that's why I disagree with this.

Lee: In an IP endpoint, is it the device that changes the IP header information.

Dave: If the source address is the source address of the end box, the net box is an input.

Erik: I agree the doc is a bit muddled because it doesn't talk about the layers. Any of these, we how the IP address on 10 different servers and that's fine, more or less. The peer doesn't look any different, and sometimes it's a host memory, and that has some changes to that behavior. It's actually multiple servers generating those IP IDs coming back. 

Dave: Security might be an aspect of an endpoint, but there's no such thing as a security end point.

Mirja: The difference is an end point is an ID and you share these. Just sharing your security credentials you should not do. 

Gabriel: I agree that there is a multiplicity of end points, and even cross-layer. What is common for all of this, there are 2 partners in semantic dialog. The partners are the end points. Doesn't mean there is only one particular location. 

Tommy: I agree about the multiplicity. There's not a 1:1 mapping, and there is going to be many of that. End points are derived from one another. There's DNS resolution. We do end point derivation and we need to revise v6 end point, proxy end points, and you know there are 1:1 and 1:many relationship. Sometimes they are equivalent and sometimes not. When we are talking about the end points.

Brian: I will take the opposite side of Dave's argument, not because I disagree. There is a very simple reality in a world where you have arbitrary manipulation of packets on the path. When I cross a domain, there is no end point to the internet. If you have a an associate where you have integrity on the bits where they go into and come out of something they are the same, otherwise it's an endpoint-less...one of the big benefits of adding security to things is not security, it's correctness. All of the bugs in your parsing code--crypto exposes those flaws. It also fixes anything where there is accidental bit flipping, or that some people run systems with different bit error rates. Crypto fixes that. If you haven't padlocked it, then it's not an endpoint. Then it is implicitly a multi-party protocol with unknown parties.

Several: Not sure about that last sentence.

Brian: Yeah... I'm not sure either.

Martin: I think we're losing an opportunity by focusing on the narrow definition Dave is talking about. I read Ted's intro to the doc, and that says something.

Brian: This is issue 5 on Github.

Martin: Let's say I initiate an action in an application. There are lots of endpoints involved in what we do from that point. Lots of semantic interactions in between, multiparty interaction in between. End points at every layer. Multiple interactions happening in different contexts. We can say all that, that then end point is the thing that is having the interaction at this layer. We can say what I just said, but Ted's statement was talking about the end to end principle and what it means and how it affects your intent to interact with people and how it ties back to identity, and all of these things are just pieces in a greater puzzle, and ultimately it is the greater puzzle and not the individual pieces.

Dave: I think Martin makes a good point, and the title "what is an endpoint" is harmful. But I think there might be 4 types of endpoints, what we mean when we're talking about unicast, anycast, multicast, and broadcast. And there may be more. And I agree with Martin.

Mirja: We have end points at different layers, maybe at cross layers.

Suresh: One thing I want to say from earlier, the evolution of the IP stuff Dave did is very good reading (RFC 6250). If we start from there would be good.

Erik: In terms of unicast/anycast, it's completely muddled. Sometimes the host name is a service, and sometimes it's a host name.  Some of the stuff, I don't know if it's helpful to point it out. 

Brian: To sum this discussion up, it seems like there is something that come out of this that is different from the draft we imagined in Montreal. There is a Github repo. Martin's screed is hard to digest. Sit down and clear some time to spend on this. There is a lot packed up in there, and I think taking the notes from the discussion, I'll copy paste it out, and Ted's reply.

Dave: Where will the discussion be?

Brian: That should be on the list. Smaller discussions can go into the repo.

Dave: Can the Github notifications be sent to the list?

Brian: Will take an action to figure that out. I think this will eat the agenda of our midterm call, and will put out a Doodle soon. 

-- Access Network Terminology

  As discussed at IAB retreat in Montreal, we have a document defining a 
  terminology of access network that misses the last decade of 
  developments in this space.

  - https://github.com/stackevo/4084-bis


ACTION ITEMS
-------------

- Natasha to push the latest version of the MaRNEW workshop report to GitHub.

- Brian to send out Doodle poll to schedule a midterm Stackevo Program call.

- Brian to figure out how to get GitHub notifications sent to the Stackevo list automatically