Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just one QUIC bit

blog.apnic.net

Post reply on HN
Print view View original

61–70 of 105 posts

Re: Just one QUIC bit

#61

Post by detaro »

datalist wrote: post #51
detaro wrote: post #50

Earlier quoted context omitted.

The article only mentions NAT as the most prominent example of middle boxes. And no, the UDP header obviously is not encrypted, if it were it wouldn't work with existing devices and OSes. UDP doesn't give you much information to mess with, which is part of why it's used for QUIC: it works through existing networks, and they can protect the deeper protocol layers against development of new middle-boxes attempting to l…

I am not sure it is that obvious given the article's focus on NAT. But what is the problem exactly then?

The problem is that if a protocol has visible parts, middleboxes will try to do stuff with those and not handle them correctly in corner cases, or when the protocol changes (e.g. TLS had issues with middleboxes attempting to verify details of the handshake and breaking or downgrading a connection when it saw options it didn't know, e.g. because a newer TLS version was used. MPTCP extended TCP and had lots of problems with things that expected specific behavior of TCP flags and parameters, where MPTCP would have liked to use them differently. With HTTP there have been issues with proxies not understanding new headers, or things like websockets. ...)

QUIC tries to prevent this by making as little as possible visible outside the encryption: it should look to a middlebox as much as possible like an opaque data stream, and not reveal any details about what's going on inside. Now there is a proposal to add something that is explicitly visible to the network, and people are worried that will come back to bite them in some way if they make an exception now.

Re: Just one QUIC bit

#62

Post by gmueckl »

IshKebab wrote: post #58
mhandley wrote: post #16

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/…

The thing I don't understand is why these network operators care about RTT outside their network? Shouldn't they only care about getting packets through their network as quickly as possible, which you don't need this spin bit for.

The global optimum might not be the combination of locally optimal routes. The shortest route through a network segment to a peer may end up being globally slower than a locally slower route to another peer which can handle the traffic faster.

Re: Just one QUIC bit

#63

Post by slededit »

bsder wrote: post #24
anameaname wrote: post #22

Earlier quoted context omitted.

Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.

Sarcastically: who will even notice a 200ms hiccup, nowadays, given the enormous waste of time that everybody shoves into their Javascript ad networks. Personally, I don't want them to expose anything . The RTT on my packets is yet another piece of metadata capable of being abused. In addition, I hope that the whole QUIC thing is a nice reboot of actually getting end-to-end connectivity back on the Internet so we can…

That's 200ms that could be used loading more tracking scripts.

Re: Just one QUIC bit

#64

Post by Steltek »

mhandley wrote: post #16

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/…

To me, excessive queueing seems indicative of network operators making assumptions about traffic and their solutions ultimately lead to worse outcomes, buffer bloat etc. Isn't QUIC meant to prevent the network from making these assumptions, forcing a more agnostic network, and letting QUIC manage congestion, latency, etc?

Re: Just one QUIC bit

#65

Post by cesarb »

pilif wrote: post #59
datalist wrote: post #56

Earlier quoted context omitted.

Thanks for the detailed response, but I am "with" you :). The bit (no pun intended) I do not understand is why there is such a discussion in the first place? Why do they insist on a plaintext status bit? Thats why I wondered if there was any encryption outside of the UDP payload.

The discussion about exposing the bit was to allow network administrators to detect retransmissions. The bit is supposed to flip constantly, if it doesn't, then retransmissions happen and thus something might be wrong with the network. Because it's just one bit and it can have two values and both are valid and both values are seen with about the same frequency, a middlebox won't be able to just drop a packet if the v…

> The bit is supposed to flip constantly

> a middlebox won't be able to just drop a packet

You do know that someone somewhere is going to make a middlebox that just drops a packet unless that bit flipped in the precise sequence that the middlebox developer believed was the correct one, right?

Then someone proposes an enhancement to QUIC which happens to change the sequence of the flips (perhaps some multipath thing, or an enhancement in the way it treats reordered packets), and it breaks...

Re: Just one QUIC bit

#66

Post by mikeash »

tialaramex wrote: post #40
ksec wrote: post #35

Earlier quoted context omitted.

Does anyone know how much buffer bloat or delay is added in the router, or CPE or Modem? I assume they are less then 1ms? I have been trying to figure this out for a while but information aren't really available.

Bufferbloat is potentially almost unlimited, assuming that the people who built it are idiots (a safe assumption for most consumer gear) it basically just depends how much they were willing to spend on RAM. For example, let's say we can move 10Mbps, and we've decided to use 10 megabytes of buffers to make our new WiFi router super-duper fast. Do a big download, the buffer fills with ten megabytes of data, that's eigh…

Back around 2006, I had a RAZR that I figured out how to use to tether my computer onto Verizon’s 1xRTT service. I’m not sure which part of the system was to blame, but something had massive buffers and a strong aversion to dropping packets. If the connection got saturated I could easily see ping times of two minutes or more.

Re: Just one QUIC bit

#67

Post by kiriakasis »

qalmakka wrote: post #8

Middleboxes have been tampering with packets and headers for way too long. It's most definitely time to move back control to the two ends of the connection, to avoid fossilisation and the same mistakes made in the past. IPv6 and QUIC are a cardinal step in this direction, and we cannot afford to let myopic decisions screw up the opportunity to fix what has been broken for so long.

I believe that lack of compatibility between IPv4 and IPv6 was more relevant than middleboxes meddling with packets.

Re: Just one QUIC bit

#68

Post by peterwwillis »

Steltek wrote: post #64
mhandley wrote: post #16

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/…

To me, excessive queueing seems indicative of network operators making assumptions about traffic and their solutions ultimately lead to worse outcomes, buffer bloat etc. Isn't QUIC meant to prevent the network from making these assumptions, forcing a more agnostic network, and letting QUIC manage congestion, latency, etc?

I think the point is that network operators want to use QUIC to measure network segments and make routing decisions. They are not necessarily trying to improve QUIC performance.

Re: Just one QUIC bit

#69

Post by woah »

Asdfbla wrote: post #42
signa11 wrote: post #27

Earlier quoted context omitted.

> interesting to know what impact the current packet inspection practices by the middleboxes have on network performance. well, all (almost ?) current boxes can do that at line rate for minimal sized packets. > incentives of the middleboxes to inspect packages(sic) incentive is for charging / billing / steering packet flows etc.

I probably expressed that wrong, I was more wondering if the packet sniffing had any beneficial impact on the performance in the sense of QoS or congestion control or something like that. After all, they have to do it for a reason. But your second points mentions it's for billing and such, so I guess that's my answer.

I don’t think it’s for billing most of the time. The middleboxes usually provide some kind of immediate benefit to the network, while breaking core networking assumptions and thus contributing to a weird form of technical debt.

Re: Just one QUIC bit

#70

Post by pcunite »

I disable QUIC in my network because I'm doing QoS at my router and utilize TCP flow control to slow things do to where I want them to be. QUIC makes the incorrect assumption that the network never wants to slowdown or to even allow for a configurable speed. Don't be too clever.
Post reply on HN