Just one QUIC bit • Hacker News Board

Re: Just one QUIC bit

#41

Post by nvarsj » Wed, Mar 28, 2018, 10:49 AM UTC

tialaramex wrote: post #32

Buge wrote: post #31

Earlier quoted context omitted.

Aren't network operators already adding artificial delay? I pay for X Mbps download speed, and my ISP artificially limits my download speed to that, even though their network is perfectly capable of providing me with more.

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, especially for ISPs with "boost" limiting). Ideally home routers would dynamically adjust based on observed latencies.

Re: Just one QUIC bit

#42

Post by Asdfbla » Wed, Mar 28, 2018, 11:33 AM UTC

signa11 wrote: post #27

Asdfbla wrote: post #19

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…

> 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.

Re: Just one QUIC bit

#43

Post by no_identd » Wed, Mar 28, 2018, 11:43 AM UTC

xtrapolate wrote: post #26

This proposal is a compromise. Wouldn't a specific metadata/heartbeat "packet", routinely dispatched by the involved parties, serve a better solution? My personal stand is to prohibit exposing any metadata on the connection whatsoever, but given the counterarguments, I don't think the proposed solution is ideal.

>My personal stand is to prohibit exposing any metadata on the connection whatsoever

https://grothoff.org/christian/habil.pdf Christian Grothoff - The GNUnet System [October 2017, 181 pages, PDF]

Re: Just one QUIC bit

#44

Post by isostatic » Wed, Mar 28, 2018, 11:47 AM UTC

tialaramex wrote: post #38

Buge wrote: post #36

Earlier quoted context omitted.

Isn't the only way to implement a bandwidth limit to delay or drop packets during specific periods?

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 past 10ms.

Re: Just one QUIC bit

#45

Post by no_identd » Wed, Mar 28, 2018, 11:47 AM UTC

tialaramex wrote: post #34

bullen wrote: post #33

Again the solution is not to reimplement TCP on top of UDP but to make TCP like UDP: https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt

A nice thing about the I-D system is that we don't have to waste RFC numbers on this sort of crank nonsense. Once upon a time the IETF would end up publishing this sort of thing as an RFC and then everybody would just ignore it, but that used up the numbers and short memorable numbers are nice, which was a shame. Now we can publish them as "drafts" which just quietly expire once their interest moves on to investigati…

>to investigating which metal foils can be made into hats that best resist government mind control rays or whatever.

You joke, but Allan H. Frey already solved that in the 1960s, just add a 2"x2" wire mesh near the temples, over the temporal lobes. Blocks all RF interaction with the brain, no tin foil hat required.

...of course, this doesn't block 'mind control rays', the only thing it actually blocks consists of the Microwave auditory effect, and the only target audience for that consists of Radar techs walking around in front of hugeass antennas. ;)

Re: Just one QUIC bit

#46

Post by datalist » Wed, Mar 28, 2018, 11:49 AM UTC

I am not sure I understood the article to be honest.

Does QUIC encrypt the actual UDP packet (meaning from IP down, including the UDP header)? If that is the case it is not UDP anymore and there will be "problems" in getting to anywhere in the first place.

If it only encrypts the UDP payload, where does NAT come in? How would that be different from what TLS does over TCP?

Did I miss anything? Thanks.

Re: Just one QUIC bit

#47

Post by detaro » Wed, Mar 28, 2018, 11:52 AM UTC

datalist wrote: post #46

I am not sure I understood the article to be honest. Does QUIC encrypt the actual UDP packet (meaning from IP down, including the UDP header)? If that is the case it is not UDP anymore and there will be "problems" in getting to anywhere in the first place. If it only encrypts the UDP payload, where does NAT come in? How would that be different from what TLS does over TCP? Did I miss anything? Thanks.

pure NATs aren't a problem for QUIC, but other middleboxes are.

Re: Just one QUIC bit

#48

Post by datalist » Wed, Mar 28, 2018, 11:55 AM UTC

detaro wrote: post #47

datalist wrote: post #46

I am not sure I understood the article to be honest. Does QUIC encrypt the actual UDP packet (meaning from IP down, including the UDP header)? If that is the case it is not UDP anymore and there will be "problems" in getting to anywhere in the first place. If it only encrypts the UDP payload, where does NAT come in? How would that be different from what TLS does over TCP? Did I miss anything? Thanks.

pure NATs aren't a problem for QUIC, but other middleboxes are.

The article specifically refers to NAT.

What other boxes would you have in mind? And is the UDP header encrypted or not?

Thanks!

Re: Just one QUIC bit

#49

Post by iknowstuff » Wed, Mar 28, 2018, 11:56 AM UTC

datalist wrote: post #46

I am not sure I understood the article to be honest. Does QUIC encrypt the actual UDP packet (meaning from IP down, including the UDP header)? If that is the case it is not UDP anymore and there will be "problems" in getting to anywhere in the first place. If it only encrypts the UDP payload, where does NAT come in? How would that be different from what TLS does over TCP? Did I miss anything? Thanks.

The article only mentions NAT as a showcase of what IP packet parsing is used for. QUIC does not encrypt the UDP header.

TLS 1.3 actually run into a lot of issues due to network ossification. QUIC has been developed to bypass TCP's ossification problem and enable quicker iteration and deployment to improve latency, congestion mitigation etc.

You could argue that if QUIC's principles were in place for TCP/IP 20 years ago, middleboxes would not have made protocol revamps as difficult as they are today. Perhaps NAT would have never been developed and we'd all be on IPv6 already.

Re: Just one QUIC bit

#50

Post by detaro » Wed, Mar 28, 2018, 11:57 AM UTC

datalist wrote: post #48

detaro wrote: post #47

Earlier quoted context omitted.

pure NATs aren't a problem for QUIC, but other middleboxes are.

The article specifically refers to NAT. What other boxes would you have in mind? And is the UDP header encrypted or not? Thanks!

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 look into them by encrypting all of it.