It's not unusual for a server to also be a router in a layer 3 link aggregation setup. It's extremely common for IPs to be load-shared amongst servers using ECMP. If each server is connected to 2 Top-of-rack (TOR) switches and advertises the route to the shared IP through both TORs, you can very easily have ICMP probes used for PMTU take the wrong route and be dropped. The result is a TCP session with a default MTU that may not work along all traversed paths and will suffer from fragmentation.
I'm not sure this statement is generally true for Netflix's use case.
UDP provides no out of order packet handling which _needs_ to be handled for video streaming. UDP is by default unbuffered throughout transport and tends to cause greater stress to client systems since they need to respond per packet rather than per traffic stream (IP+port combo). As a client developer, you end up reimplementing 90-95% of what TCP gives you out of the box at great development and QA cost. You also drain battery on mobile devices with all the interrupts your causing doing UDP. The upside with a UDP-based implementation is the latency from server to client display is usually much less (tens of milliseconds vs hundreds to thousands), but the trade-offs involved are almost never worth it for a static media streaming site like Netflix.
Even dynamic media streaming sites like Twitch rarely dip into UDP server-client implementations unless there are some unusual requirements.
This isn't the whole story. Discord also mines user data and sells it to advertisers:
"Information You Provide: We collect information from you when you voluntarily provide such information, such as when you register for access to the Services or use certain Services. Information we collect may include but not be limited to username, email address, and any messages, images, transient VOIP data (to enable communication delivery only) or other content you send via the chat feature."
"Data We Collect Automatically: When you interact with us through the Services, we receive and store certain information such as an IP address, device ID, and your activities within the Services. We may store such information or such information may be included in databases owned and maintained by affiliates, agents or service providers. The Services may use such information and pool it with other information to track, for example, the total number of visitors to our Site, the number of messages users have sent, as well as the sites which refer visitors to Discord."
"If you do not wish to receive personalized advertising that is delivered by third parties outside of the Discord Service, you may be able to exercise that choice through opt-out programs that are administered by third parties, including the Network Advertising Initiative (NAI), the Digital Advertising Alliance (DAA). Our Services currently do not respond to “Do Not Track” (DNT) signals and operate as described in this Privacy Policy whether or not a DNT signal is received, as there is no consistent industry standard for compliance."
I say this as an avid user of Discord, which I use on a daily - dare I say hourly - basis. I'm perfectly fine with them collecting data on my gaming habits and the harmless stuff I talk about with friends. I don't think I would be okay with running a business through them, especially one in a similar vertical.
Collusion is when the parties coordinate on the price increases. If they both increase prices independently to achieve profitability, then I don't believe that to be illegal.
No. That's not how price collusion works. If Delta airlines started charging for 2nd baggage, and after their announcement United/American/Southwest follow suit, that's not a price collusion if it wasn't predetermined secretly through implicit and explicit signaling among the airlines. The other airlines had option of either increasing their margins by adding new fee, or keeping 2nd bag free and hoping to make more money with increased volume (profit = unit margin volume). They are free to choose former or latter in our capitalistic setup. If there aren't any easily available substitutes, and you don't expect some new entrant to come and distrupt you, first option becomes much more lucrative. Especially if you have negative unit margins, since with second option - negative marginshigher volumes = lots of losses
> If Delta airlines started charging for 2nd baggage, and after their announcement United/American/Southwest follow suit, that's not a price collusion if it wasn't predetermined secretly through implicit and explicit signaling among the airlines.
I understand that.
That's why I said "suspicion". Something that seems too convenient and warrants some more poking and prodding and surveillance.
It's not as though folks colluding walk around waving "I am colluding, please investigate further" placards.
However, in the case of mitigation of a Denial of Service attack, using IP blocking is an effective temporary measure.
From my experience in dealing with HTTP DDoS-style attacks there's usually a pretty consistent block of IP addresses where the attack originates from, i.e. an AWS or Hetzner IP range. When the choices are to block IPs temporarily or have the entire service go down due to resource exhaustion, the choice is pretty clear cut.
We'd implement the block to keep our service up then report attacker IPs to AWS or whoever maintained the range in question. As the attack waned, we'd re-enable the range.
Of course, IP blocks usually did not work as well with udp-based reflection style DDoS mitigation, but we'd still see certain IP ranges responsible for significant portion of the attack.
We ran our own hardware though, so resources like CPU and inbound bandwidth weren't elastic enough to outpace an escalating DDoS past 120-140 Gbps. We also eventually moved to adding DDoS mitigation through third parties like CloudFlare.
Ones like Strangeloop out in St. Louis offer an incredible diversity of talks, topics, and forums offered: from language deep dives and workshops to architecture talks to rather arcane talks about modifying an automatic sewing machine to print jpegs onto sweaters and more casual forums on topics like validating resilience and durability guarantees of different datastores.
Ones like Google's series on GCP are exactly as you described though.
If you have your own dedicated IP range and you are advertising routes correctly, then you're as close to ownership of your IP addresses as Google or Facebook are of theirs.
ARIN and RIPE control allocations, but do not control routing to allocated ranges.
I think the point GP was making is that you don’t “own” IP addresses, you effectively “lease” them. If you don’t pay your ARIN (or others) dues, you’ll lose them.
Even with peering in place behind the scenes, cloud providers would still usually charge for egress from storage and cdn services to a provider like cloudflare.
What Cloudflare et al are doing here is utilizing the peering connections that they have already in place and not billing at the usual egress rate when traffic routes over these peering connections.
There are a few internal sources Uber could be getting its mapping data from[1][2]
These acquisitions came around the time Uber was pivoting into a logistics company. It wouldn't be too surprising if they had a pretty rich 3d map dataset of a few test cities. Especially if they had deployed autonomous cars in them.
