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

71–80 of 105 posts

Re: Just one QUIC bit

#71

Post by catern »

gmueckl wrote: post #62
IshKebab wrote: post #58

Earlier quoted context omitted.

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.

That's fine. If global optimization turns out to be significant, we can do it at the edge with overlay networks. No need for network operators to be involved.

Re: Just one QUIC bit

#72

Post by silotis »

pdkl95 wrote: post #11

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

This was my first thought as well. I would love to see the reaction from the pro-spin-bit camp if Google announced that Chrome will never set the spin bit.

Re: Just one QUIC bit

#73

Post by nine_k »

catern wrote: post #71
gmueckl wrote: post #62

Earlier quoted context omitted.

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.

That's fine. If global optimization turns out to be significant, we can do it at the edge with overlay networks. No need for network operators to be involved.

> we can do it at the edge with overlay networks

Is this really easy to do, with negligible overhead, and no need to seriously reconfigure what you already have?

Re: Just one QUIC bit

#74

Post by gene91 »

This idea of forbidding middlebox from messing up things sounds great. I have an honest question here though.

What stops a middle box from terminating all QUIC connections (and therefore get access to decrypted content)?

Re: Just one QUIC bit

#75

Post by ElijahLynn »

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

You may have done this already, but I encourage you to copy/paste this as a comment on the article at apnic.net so it has more visibility. The opening line about "It was actually a very civil discussion, and I think almost everyone in the room could see both sides on the issue." needs to be shared.

Re: Just one QUIC bit

#76

Post by tialaramex »

nvarsj wrote: post #41
tialaramex wrote: post #32

Earlier quoted context omitted.

No. Bandwidth limits and delay aren't the same thing. CPE (the WiFi router or similar in your home) often adds delay because a few megabytes of RAM is cheap and the people who built it don't understand what they're doing. This is called "buffer bloat". But inside the network core this rarely comes up.

You need buffers to maintain high bandwidth. There is no way around that. The problem is lack of AQM in end user routers - where a single high bandwidth flow can fill up and hog those buffers, disrupting latency sensitive flows. We're slowly seeing some adoption of things like fq_codel, but it's not perfect since the user has to go and manually enter their upload/download speeds (which again are not easy to determine…

Codel is knobless, there literally aren't parameters you _can_ set let alone ones you need to set according to your "upload/download speeds". So, I have no idea what you're tinkering with that you think needs to know "upload/download speeds" or why, but it's nothing to do with Codel.

Re: Just one QUIC bit

#77

Post by tialaramex »

isostatic wrote: post #44
tialaramex wrote: post #38

Earlier quoted context omitted.

The only _sensible_ thing you can do if the transmitter won't stop is to ignore them, and thus drop packets, yes. Queueing them up instead makes some artificial benchmark numbers look good but is a horrible end user experience, so you should never do this, but lots of crap home WiFi type gear does. So, as I said, bandwidth limits and delay are different. The canonical "station wagon full of tapes" is illustrative, it…

I would far rather my udp packet is delayed by a millisecond than dropped. I have an RTP stream running from India to Europe at the moment, 3000 packets per millisecond, so 0.33ms between pacekts. Typical maximum interpacket delay is under 1.5ms, looking at the last 400,000 seconds of logs, 200k are 1-2ms, 170k are 0-1ms, and about 4-5k on the 2-3ms gap, 3-4ms gape, etc. Less than 1% does interpacket delay increase p…

You would rather all your UDP packets are delayed by a millisecond rather than have one dropped? Why?

Re: Just one QUIC bit

#78

Post by floatboth »

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…

Why would a single big download fill the buffers? Router → LAN is typically an order of magnitude more bandwidth than internet → router, so shouldn't the buffer be emptied faster than filled?

Re: Just one QUIC bit

#79

Post by zlynx »

pcunite wrote: post #70

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.

Just ruthlessly drop QUIC packets that are over the flow control limits. It will adapt.

Playing games with TCP settings is fun I guess, but simple RED with ECN and drop work well with fewer bad side-effects.

Every Internet protocol expects packet drops on overload. What was that about being too clever?

Re: Just one QUIC bit

#80

Post by floatboth »

gene91 wrote: post #74

This idea of forbidding middlebox from messing up things sounds great. I have an honest question here though. What stops a middle box from terminating all QUIC connections (and therefore get access to decrypted content)?

QUIC uses TLS, so it's pretty much the same situation as any other TLS connection.

Of course in a corporate environment you can trust the middlebox's CA on all the work machines. That's actually fine. What everyone seems to hate here is middleboxes that don't terminate connections and try to mess with them in other ways.

Post reply on HN