Just one QUIC bit • Hacker News Board

Re: Just one QUIC bit

#11

Post by pdkl95 » Wed, Mar 28, 2018, 7:45 AM UTC

> The client echoes the complement of the last seen bit when sending packets to the server.

Since neither the client or server care about this big, there doesn't appear to be anything that forces the client to actually implement this behavior. The client could always set it to 0 or even set it (pseudo-)randomly on each packet.

The bit shouldn't exist, but if the IETF did add it to the standard, would hostile middleware boxen actually start drooping packets if they don't see the "spin bit" change?

Re: Just one QUIC bit

#12

Post by IshKebab » Wed, Mar 28, 2018, 7:48 AM UTC

nicky0 wrote: post #9

giovannicarruba wrote: post #5

IMO the article completely fails to describe the actual issue. - "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward." Nice try, but if the outer layer is UDP, then NA…

The point is that QUIC is supposed to be fully encrypted below the UDP layer. The question is why add bits in the clear on top of this to water it down and open an avenue for potential abuse.

Yes but it doesn't really say why anyone wants this spin bit. What are they going to do with it? Measure RTTs? Why? What for?

Re: Just one QUIC bit

#13

Post by corndoge » Wed, Mar 28, 2018, 7:49 AM UTC

giovannicarruba wrote: post #5

IMO the article completely fails to describe the actual issue. - "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward." Nice try, but if the outer layer is UDP, then NA…

It seems you were the one who completely failed to understand the article. Your first point implies you think the author was talking about QUIC in that section, when instead the author was merely using NAT as an example of packet inspection to provide context to the topic. Your second point is in fact exactly the point of the entire article, which itself is a commentary on the decision making process and factors in that process that IETF is presently using to decide exactly how much to "break" the protocols, and moreover on the observation that many people in the IETF do not consider this to be "breaking" at all. Your third point is a commentary on the utility of the bit itself, which is not really the focus of the article anyway.

You claim: "IMO the article completely fails to describe the actual issue."

How so?

Re: Just one QUIC bit

#14

Post by IshKebab » Wed, Mar 28, 2018, 7:51 AM UTC

nicky0 wrote: post #10

tzahola wrote: post #7

What’s even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?

Network engineers can use it to monitor network performance.

How though, because surely it includes the time outside the observers network? And if they only want to monitor performance inside their network nothing so them from using an out of band system, or even adding their own timing footers to packets.

Re: Just one QUIC bit

#15

Post by erpellan » Wed, Mar 28, 2018, 7:51 AM UTC

nicky0 wrote: post #10

tzahola wrote: post #7

What’s even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?

Network engineers can use it to monitor network performance.

Which they could presumably also do by injecting their own packets, not snooping on everyone else's?

Re: Just one QUIC bit

#16

Post by mhandley » Wed, Mar 28, 2018, 7:54 AM UTC

I was in the IETF meeting. It was actually a very civil discussion, and I think almost everyone in the room could see both sides on the issue. On the one hand, we've seen increasing problems with middleboxes making assumptions about end-to-end protocols, and this making it very hard to then deploy new end-to-end functionality. The problem is real; we measured this effect in this paper:

http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend-tcp.p...

Indeed, one of the changes the IETF group has made since taking on QUIC is to also encrypt the QUIC sequence numbers, so middleboxes can't play silly games by observing them (they were already integrity protected).

However, the flip side is that network operators do use observations of network round trip time gained from passive observation of traffic so as to discover if traffic is seeing excessive queuing somewhere. An inability to do this with QUIC may either lead to worse network behaviour, or to them using other methods to gain insight. If you're in a location where you can observe both directions of a flow, you can easily do this by, for example, delaying a bunch of packets by 200ms, then letting them go. When you see a burst of (encrypted) ack packets return, you can deduce the RTT from your observation point to the destination. I'd really like to avoid operators thinking they need to do such hacks just to measure RTT, and the spin bit lets a passive observer see the RTT.

In the end, I was not convinced entirely by either argument, and neither was the consensus in the room. It's not a clear-cut decision; there are reasonable arguments either way. Such is engineering.

Re: Just one QUIC bit

#17

Post by wpietri » Wed, Mar 28, 2018, 7:55 AM UTC

Nice. I especially like this bit: "Sometimes difficult choices admit to no sensible compromise between them and the process simply has to make a contentious decision one way or the other. While individuals make such decisions all the time, the collective process that enlists a large group of diverse perspectives, interests and motivations finds such decision making extraordinarily challenging."

Re: Just one QUIC bit

#18

Post by Lazare » Wed, Mar 28, 2018, 7:56 AM UTC

giovannicarruba wrote: post #5

IMO the article completely fails to describe the actual issue. - "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward." Nice try, but if the outer layer is UDP, then NA…

> Nice try, but if the outer layer is UDP, then NAT alters the UDP packet headers. The QUIC payload is never touched.

You didn't understand the article. It's talking about existing TCP traffic here, not QUIC.

> I don't see why the people tasked with standardizing Internet protocols now have to make provisions for the jerks who literally break the Internet.

1) A lot of them are the same people and 2) internet protocols are worthless without adoption, which is why we're still groping towards IPv6.

Or for a shorter answer: Politics.

> How is this bit even useful for anything?

Here's an internet draft proposing adding a spin bit which discussed, among other things, some uses for it: https://tools.ietf.org/html/draft-trammell-quic-spin-01

Re: Just one QUIC bit

#19

Post by Asdfbla » Wed, Mar 28, 2018, 7:59 AM UTC

As someone only superficially familiar with networking, I think it would be interesting to know what impact the current packet inspection practices by the middleboxes have on network performance. After all, the article mentions that those middleboxes want to control the message flow and use that as justification. The assumption behind QUIC seems to be that there's no "global" benefit in that specific kind of network management and that it's mostly selfish interests of local network operators that motivate messing with the packets?

Basically, what are the incentives of the middleboxes to inspect packages and what do they really stand to lose?

Re: Just one QUIC bit

#20

Post by mhandley » Wed, Mar 28, 2018, 8:03 AM UTC

tzahola wrote: post #7

What’s even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?

Knowing the RTT seen by actual user traffic is useful because, for example, it lets you observe if that traffic is encountering excessive queuing. It's hard to know this by other means; for example you may think you can just ping the end systems, but these days ICMP is often filtered, and even it it wasn't, the test probes may be queued differently due to weighted fair queuing, or even take a different path due to equal-cost-multipath routing. In the end, the only true measure is what the traffic itself experiences.

Now, whether it is necessary for operators to know if user traffic is seeing excessive queuing is open to debate. But the fact is they do currently use this as one network health measure.