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

91–100 of 105 posts

Re: Just one QUIC bit

#91

Post by IncRnd »

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…

If you are running over UDP, that is so that packets get dropped while preserving the overall "stream". That is actually the purpose for the design of RTP over UDP.

Re: Just one QUIC bit

#92

Post by marshray »

tangent128 wrote: post #60
breatheoften wrote: post #55

There are still environments where active policies described by network operators to manage traffic flows is _required_ for users to make any productive use of the network ... I used to work on research ships — 50 people at sea for months at a time with satellite internet having only 256kbps (800ms latency). It was abysmal to watch as over time everyone became completely dependent on internet connectivity for their c…

The"correct" answer there is probably to make the network limits explicit, by explicitly requiring a proxy server or organization CA installed in the client. QUIC should still work with middleware that actually terminates the connection instead of meddling from outside.

Sounds like Android at least can be told via DHCP it's on a metered connection:

https://www.reddit.com/r/networking/comments/4wk4rw/dhcp_opt...

Re: Just one QUIC bit

#93

Post by isostatic »

bsder wrote: post #90
isostatic wrote: post #44

Earlier quoted context omitted.

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…

Then you should have forward/backward error correction in RTP so you can completely ignore the packet drop/delay.

Standard SMPTE FEC doesn't allow more than 20 columns of error correction, at 30mbit that's about 7ms of drop, at best of times (assuming the required FEC packets aren't lost as well). At low bitrates it works better, and the majority of our international vision circuits rely on single streams with FEC. Had one ISP in the Ukraine that had an intermittent fault where, regardless of the bitrate, they would occasionally drop 170ms of traffic.

I currently have a difficult provision that for a variety of reasons I can't use ARQ on. To keep the service working I have 4 streams going, over two routes, with timeshifting on the streams to cope with route-change outages that tend to sit in the 20ms range. FEC is meaningless at these bitrates.

RTP is fine for delay and re-orders, but it doesn't cope with drops. I was at a manufacturer's earlier this week and said that I've experienced dual streaming skew of over 250ms (we had one circuit presumably reroute via the US), and I laugh at their 150ms buffer. Dual streaming can still fail when you have both streams runnning on the same submarine cable though. Trust me, intercontinental low latency interoprable broadcast IP on a budget isn't trivial

Re: Just one QUIC bit

#94

Post by isostatic »

IncRnd wrote: post #91
isostatic wrote: post #44

Earlier quoted context omitted.

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…

If you are running over UDP, that is so that packets get dropped while preserving the overall "stream". That is actually the purpose for the design of RTP over UDP.

RTP runs over UDP

Re: Just one QUIC bit

#96

Post by floatingatoll »

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.

Yes. Market correction isn’t applicable in most US markets, which have either a broadband monopoly or duopoly for broadband service.

Re: Just one QUIC bit

#97

Post by rphlx »

no_identd wrote: post #45
tialaramex wrote: post #34

Earlier quoted context omitted.

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…

> the only target audience for that consists of Radar techs walking around in front of hugeass antennas

And perhaps US diplomats in Cuba.

Re: Just one QUIC bit

#98

Post by IncRnd »

isostatic wrote: post #94
IncRnd wrote: post #91

Earlier quoted context omitted.

If you are running over UDP, that is so that packets get dropped while preserving the overall "stream". That is actually the purpose for the design of RTP over UDP.

RTP runs over UDP

That's exactly my point.

Re: Just one QUIC bit

#99

Post by muxator »

isostatic wrote: post #89
tialaramex wrote: post #77

Earlier quoted context omitted.

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

Because that UDP packet is important, it can lead to millions of people watching a TV program having a 3 second outage in their audio.

The need to protect against this type of problems is the reason for which Forward Error Correction is included in almost all the codecs.

Moreover, since your specific use case is not interactive conferencing, but IPTV, there would be no problem in incrementing even more the FEC ratio, at the cost of a small decoding latency.

Re: Just one QUIC bit

#100

Post by nvarsj »

tialaramex wrote: post #76
nvarsj wrote: post #41

Earlier quoted context omitted.

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.

fq_codel alone doesn't solve buffer bloat. There are still huge buffers upstream. You need to combine it with local rate limiting so you can control the buffer in your local home router. fq_codel/cake work by looking at time a packet spent in a local queue. If you don't rate limit locally, then your local queue is always empty and everything queues upstream. Modern routers with things like "Dynamic QOS" that use fq_codel all require providing downstream/upstream values. This is way simpler than more traditional qos, but it's still a barrier to wide spread adoption.
Post reply on HN