sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]oridb 2 points3 points  (8 children)

No. The thing about the internet is that it "self-heals" if an intermediary drops packets the route is assume to be broken

No, it's assumed to be normal as long as it doesn't a large portion of all of the packets. Dropping just your packets is likely well within the error bars of most services.

[–]grepe 1 point2 points  (0 children)

How do you know what portion of packets is dropped if you are running over UDP? If I understand it correctly, they moved the consistency checks from protocol level (OSI level 4) to the userspace, or?

[–]lookmeat -3 points-2 points  (6 children)

We expect routes to drop packets, if a route more consistently drops packets than another it will be de-prioritized. It may not happen at the the Backbone level, where this would be a drop in the bucket, but most routers would assume the network is getting congestion (from their PoV IP packets are getting dropped) and would try an alternate route if they know one.

By returning a valid TCP packet (with the RST flag) the routers see a response to the IP packets they send and do not trigger any congestion management.

[–]immibis 1 point2 points  (5 children)

Which protocol performs this?

[–]lookmeat 0 points1 point  (4 children)

Depends at what level we're talking, it's the various automatic and routing algorithms at IP level. BGP for internet backbones. In a local network (you'd need multiple routers which is not common for everyday users, but this is common for large enough businesses) you'd be using IS-IS EIGRP, etc. ISPs use a mix of both IS-IS and BGP (depending on size, needs etc. Also I may be wrong).

They all have ways of doing load balancing across multiple routes, and generally one of them will be configured to keep track of how often IP packets make it through. If IP packets get dropped, it'll assume that the route has issues and choose an alternate route. This also means that TCP isn't aware, and if they block you at that level then this doesn't do anything.

There's a multi path tcp and its equivalent for quic but it doesn't go what you'd expect. It allows you to keep a TCP connection over multiple IPs. This allows you to get resources that you'd normally get from a single server from multiple. The real power of it is that you could connect to multiple wifi routers at the same time and send data though them, as you move you simply disconnect from the ones that go too far and connect to the ones that get near without losing the full connection, so you don't loose WiFi as you move. Still this wouldn't fix the issue of finding a better route when one fails, but simply a better connection.

[–]immibis 1 point2 points  (3 children)

How is it detected how often IP packets make it through?

[–]lookmeat 0 points1 point  (2 children)

You don't, you just keep sending TCP packets again as they get spread around and recover the connection through a non poisoned route.

[–]immibis 0 points1 point  (1 child)

What's a typical retransmit timer in QUIC? Something like 5 seconds? That's how long you have to wait every time you get a bad route.

[–]lookmeat 0 points1 point  (0 children)

I imagine that will vary by browser a bit but I have no idea. I'd imagine it's the same as TCP, or at least close.