[Stackevo] Stackevo Notes, IETF 103

[Tommy Pauly <[e-mail]>]

Thanks everyone for meeting today! Here are the notes I took—apologies for any lossy reception.

Best,
Tommy

===========================

Tommy:
We have three documents (Path Signals, Wire Image, Use It or Lose It)
How do we know which aspects work? Can we measure when things do get blocked? Are we going to be able to measure ossification around things like spin bit? 
If we’re doing certain things all the time because we believe they work, there’s likely no way to know their effect; do we compare to TCP?
Can we tell if adding this actually improves other protocols’ ability to move ahead?

Martin: When Google enabled greasing in Chrome it discovered problems in lots of TLS deployments

Eliot: Different results at different layers. Sounds great at application layer, not so much at IP layer

Aaron: Pervasive encryption; can we reason about is the benefit worth the cost. MAPRG satellite proxies.

Ted: It ends up being apples to oranges, and the encryption ends up being a confounding factor

Aaron: It’s a naive approach, but that’s a step, in their defense

Martin: Dynamics in TLS made greasing effective. Around IP, however, Eliot suggests that it may come crashing down. What’s the difference?

Eliot: Not point to point, will have different failure modes

Suresh: The ossification already happened in IP, and it’s quite hard to get anything through

Aaron: Regarding TLS, what was the feedback path?

Martin: You can often tell who’s at the other end, you can know which stack you talk to. Middlebox tolerance was more difficult to fix. Talk to server IT people

Suresh: Stuck for IOAM measurements in the IPv6 headers, adding the new headers fundamentally change the behavior

Ted: How can we help from this group? How do we scale? When you build a new protocol, build an in-band type of ICMP to get feedback.

Spencer: You can get feedback through at many different layers

Gabriel: How do we have arrived? QUIC is our delivery vehicle. When we do things, we do A/B testing.

Christian: Satellites and low speed; there is a pattern that most of the software is built for the mainline, and people outside of the mainline and those with narrow land lines in Africa, etc; how do we surface those narrow cases so that we actually test them?

Mirja: We go for mainline for business interest; but we need to test in the edge cases

Eliot: Be careful about characterizing Africa as mainline vs non mainline. IoT devices look a lot like Africa. In reaction to Ted, where does the OAM layer belong, and detecting failures and treating them? When Brian started this effort, it was that, but now it feels like how to make QUIC work everywhere. How do we bring back info to OAM. We could have a document asking the question of who is responsible for OAM in this new world.

Martin: We built something for Web Push that was useful—we added contact information to the endpoints to identify themselves. The privacy implications are *interesting*. The website identifies itself to the web service. Interactions at that high level can be beneficial for the network layer.

Aaron: Which identity?

Martin: The person responsible for maintaining the thing

Suresh: With packet too big ICMP errors, entire connections get torn down. That means that path MTU discovery breaks connections.

Tommy: TLS greasing was added later and found issues. QUIC is the first protocol with greasing from the beginning. How little greasing can we do? Should this be varied to explore the space? Can we measure the harm to the network layer, such as with the spin bit being turned off? These are different audiences.

Aaron: Returning to developing world, discussed with technical fellows from Africa. They were all faculty members from universities. Seeing how people can get involved and get visibility. We should help encourage informational RFCs about the infrastructure and facts about deployments in these places we’re less familiar with. We should be able to test against such cases so we know what we’re messing with.

Mirja: Agreeing with Eliot, “where is the OAM layer”? It’s at every layer, and we’ve not been treating it as an explicit function, and more as a side effect.

Eliot: It’s the interfaces of the OAM parties that is suffering now.

Ted: Agreed with Mirja that it’s a function, but we really don’t have any layers any more. We see abstractions that are no longer helpful.
Returning to the bigger question, who’s responsible—is it the boxes in the middle or the boxes at the ends? For things like path MTU discovery, can we give better signals that are trustable (like just saying “this in my max mtu, stop asking per flow”).

Gabriel: We’ve spent the majority of the time talking about operations and measurement. Starting to deploy stuff. We don’t have many people here who are ops area people, however. Look at how long it took to do the spin bit. When we have a v2, what else will we want to add? How can we remove the anguish of this decision around the tradeoff.

Erik: Often, packets are lost without signaling. Sometimes the network can explicitly say that, if you want to trust it. Still just a hint. If you were to design a new path MTU, we can even get more information without fully trusting it (since we can have reasonable bounds)

Mirja: Plus had a proposal for that to have the layers tell things in a protected way. If you drop a packet, that’s the one case where you need to communicate in an untrusted manner.

Eliot: Customer has a scenario in which he wants to signal to the network that it should rate limit certain flows for a certain time. Question is how we know what’s true. We shouldn’t ignore layer 2 solutions here.

Spencer: I started with performance implications of link characteristics; and someone said, rather than having a TCP for every challenged networks, figure out how to deal with the different kinds of challenges. Can we make this set of challenges a regression testing for internet protocols?

Aaron: You could look at QUIC performance over a bunch of different link characteristics. Look at PILC RFCs.
There’s also another layer of variations that PILC didn’t look at that’s more operational constraints or relationship constraints between deployments.
Maybe we should start greasing the top 5 networking protocols, to explore the spaces of protocol options.

Eliot: John Gilmore wants to look at opening up 240/4 (class E). It’s specifically dropped in many stacks. What does greasing get you there? 

Aaron: I think greasing and racing are closely related, so you can fail over to the non-greased case

Martin: We’re talking about greasing more like fuzzing. Your protocol may be implemented across various boxes, and you want to test it. It’s fuzzing a protocol. In politics, a minority can gain control by being intolerant, and everyone else not caring. You can have “good” implementations be loud about it to stop the bad deployments.

Aaron: That works better for end systems than middleboxes

Dave: My response to John Gilmore (see Eliot’s comment) was isn’t it easier to get people to do IPv6 rather than updating all the middleboxes for class E?

Christian: Greasing is about checking whether the door can still open. We can do an inventory of protocols that matter, SMTP, TCP, etc., and find which doors are still open.

Mirja: That’s some of what the MAMI project does. We tried to do this in a generic way, but you need to fall within the semantics of the protocol. We also don’t have very good test coverage.

Tommy: Can we just bake in the measurements to the new protocols to see how these tests go?

Ted: Outcomes are:
Take existing protocols, and see which doors are still open using greasing
Look at the PILC work and see if something has changed about critical link characteristics, and if things change with more UDP protocols
Research group looking at advisory methods at a different layer than ICMP
Can IRSG people float a BOF on this?