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

31–40 of 105 posts

Re: Just one QUIC bit

#31

Post by Buge »

anameaname wrote: post #22
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/…

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.

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.

Re: Just one QUIC bit

#32

Post by tialaramex »

Buge wrote: post #31
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.

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.

Re: Just one QUIC bit

#34

Post by tialaramex »

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 investigating which metal foils can be made into hats that best resist government mind control rays or whatever.

Re: Just one QUIC bit

#35

Post by ksec »

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.

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.

Re: Just one QUIC bit

#36

Post by Buge »

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.

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

Re: Just one QUIC bit

#37

Post by nicky0 »

erpellan wrote: post #15
nicky0 wrote: post #10

Earlier quoted context omitted.

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?

I don't know, how would you inject packets into an encrypted end to end connection?

Passive observation of traffic is a useful network performance monitoring technique.

Re: Just one QUIC bit

#38

Post by tialaramex »

Buge wrote: post #36
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.

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 has _tremendous_ bandwidth but _enormous_ delays. In contrast a mid-century POTS telephone call from London to Glasgow has almost no delay (barely worse than the speed of light) but bandwidth is tightly constrained.

Re: Just one QUIC bit

#39

Post by nicky0 »

IshKebab wrote: post #14
nicky0 wrote: post #10

Earlier quoted context omitted.

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.

Read this comment: https://news.ycombinator.com/item?id=16696159

Re: Just one QUIC bit

#40

Post by tialaramex »

ksec wrote: post #35
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.

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 eight whole seconds of transmission, now the latency of packets is eight seconds, so that's 8000 times larger than your "I assume less then 1ms".

{Edited to correct numbers}

Post reply on HN