I'm unsure why the distinction matters that was brought up in the post. It really comes down to what do you need to support, and how much weight you can swing.
Are you a small time supplier, and want a major retailer to integrate with you over API? good luck. The decision really isn't yours, if you want to get paid, you integrate.
I think the reality is that most developers would rather use an JSON API instead of EDI. EDI is sometimes talked about as just X12 / EDIFACT, but the protocol is baked in as well, which causes more headache (who wants to build an EDI stack?). X12 was built during a time where VANs probably connectivity, and caused per character, so everything was positional based and inferred. Modern APIs are descriptive, and easier to use.
(fd: I work for Orderful, a company that provides an API and then translates it to EDI so you can easily work with any trading partner)
My dad passed away with dementia in 2019, spent a lot of time in nursing homes and also making decisions about the care of my father. I actually got to see this first hand with his caregivers in his facility. The requests to put him on different drugs required me to do a lot of research, validation and getting out of pocket advice from a medical professional that wasn't associated with the care facilities.
As someone that has gone through this, there is a fine line to walk between doctors operating under their Hippocratic oath, caregivers, and patient wishes. My dad was prescribed meds that weren't helping his quality of life and had really bad side effects mentally and physically through the the mid-stages of dementia.
Being in the authentication/authorization space for a while, this couldn't be truer. If OAuth 2.0 was a compelling differentiator from your API standpoint, they are doing it wrong.
I love how Ajit keeps saying 'it does not happen' where traffic is limited or blocked. It was limited, we saw this by Comcast with Netflix back in 2014.
This is what we are getting ready to get back into. I do not want to have an internet where the ISP can hold me (the consumer) hostage to other companies to increase the ISPs bottom line. It isn't a good experience for the consumer, it isn't a good experience for providers of media and apps.
> It was limited, we saw this by Comcast with Netflix back in 2014.
This was due to a peering dispute with Cogent over link saturation and maintenance costs, not Comcast throttling Netflix traffic. Netflix ended up peering directly with Comcast in order to bypass Cogent's bottlenecked links. Neutrality regulations have jack-all to do with peering mutual maintenance agreements.
> Neutrality regulations have jack-all to do with peering mutual maintenance agreements.
Can you please write more about this, or provide some links where I can learn more? I don't feel I have an understanding of how peering would change under proposed net neutrality rules.
Particularly, I am curious about the claim that "[Comcast was not throttling Netflix traffic]". Under the proposed FCC rules, would it be claimed that they were throttling in that 2014 situation? My understanding is that they would be seen as throttling, and I see that as a problematic outcome because Comcast loses significant bargaining power and essentially is forced to eat losses whenever a link becomes saturated... I think I read that the FCC would step in and mediate such talks, which is even crazier.
> I don't feel I have an understanding of how peering would change under proposed net neutrality rules.
tl;dr: I don't think the neutrality end of the rules would change peering at all, and peering disputes are never grounded in the kinds of things that neutrality seeks to protect. Title II classification permits the FCC to arbitrate peering disputes, which is a desirable side effect for people who just want to watch Netflix without buffering, but doesn't make it a neutrality issue.
Longer version:
Netflix reached Comcast customers through a third-party transit provider named Cogent. Cogent and Comcast have their networks connected together, and Netflix's volume of traffic was such that the links from Cogent -> Comcast became saturated, resulting in congestion and traffic issues for Comcast customers trying to get their packets from Netflix to their Comcast line. Non-Netflix traffic on this same link degraded, as well - but Netflix was the lion's share of the traffic, and online video tends to be more visibly sensitive to congestion issues than most other forms of traffic, so Netflix became the poster child for the problem.
Cogent and Comcast had a settlement-free peering agreement, broadly meaning that they agreed to exchange traffic with one another without charging for it, and with each side reasonably contributing to maintaining its end of the link. I'm remembering the details vaguely, but IIRC, Comcast claimed that the agreement's settlement-free status depended on maintenance of a roughly equal exchange ratio - traffic in from Cogent to Comcast should be appropriately balanced with traffic out from Comcast over Cogent. Netflix in particular skewed the ratio hard such that traffic in massively outweighed traffic out.
Historically, settlement-free peering agreements included provisions (or at least an understanding) that each party would built out their half of link capacity necessary to handle the exchanged traffic. As demand goes up, each party is responsible for contributing to the link's overall capacity. Comcast's claim was that Cogent's traffic ratios were so out of whack that Cogent should pay for the link upgrade. Cogent refused to pay for the link upgrade, citing the settlement-free nature of the peering relationship. Since nothing got upgraded, the link remained saturated in the face of increasing demand, until Netflix got tired of Comcast and Cogent slap-fighting and peered directly with Comcast, so they could deliver their bits directly to Comcast's customers without having to go through a transit provider (they had previously had similar issues with Level3, another transit provider). As I understand it, Cogent has a reputation for abusing traffic balances to offer cut-rate transit - they have a long and storied history of fierce peering disputes with a large number of peers, which makes me somewhat sympathetic to Comcast's position in this case (ick!)
So, as I understand it, Comcast was "throttling Netflix traffic" in the same way that a straw throttles nitrogen flow when you blow air through it - that is, traffic (air) was congested and limited, but it wasn't limited because it was Netflix (nitrogen) traffic, it was limited because the link was saturated (the straw was full of air), and it didn't really matter if it was Netflix or email or porn or what - if it went over that link, it was subject to routing issues. It's my non-expert, non-legal opinion that Comcast wouldn't be in violation because the Open Internet Order applies to a company's management of its own network, not of the interconnection points between networks, and because link saturation is not "impair[ment] or degrad[ation of] lawful Internet traffic on the basis of content, applications, services, or non-harmful devices". As long as all packets are congested equally, it's still being treated neutrally!
It's my opinion that Comcast absolutely was using Netflix's traffic as a bargaining chip to try to force Cogent into paying for the upgrade. Whether that was justified or not is a lot more nuanced than "omg, Comcast is blocking my Netflix, they must be evil!", though. As pertains to the regulations, Title II classification does grant the FCC the authority to step into peering disputes and take action if it deems a company's actions in a peering dispute to not be "just and reasonable", and would have allowed the FCC to step in and slap one party into compliance, thereby fixing the issue. That isn't a neutrality issue, though, and I'm not all that sure that Comcast would have been the losing party in an FCC mediation of the dispute.
> Comcast claimed that the agreement's settlement-free status depended on maintenance of a roughly equal exchange ratio - traffic in from Cogent to Comcast should be appropriately balanced with traffic out from Comcast over Cogent.
Eh, Comcast was being extremely disingenuous, trying to act like a Tier 1 ISP.
For Tier 1s like Cogent, they expect to more or less equally peer. Ie. BGP routes and the physical routers themselves should be setup so that a main, backbone style ISP would receive about as many bytes on an individual connection as they transmit. This makes sense for backbone ISPs, or else they end up in the situation where an ISP is essentially using another ISP's infrastructure to route their own customer's traffic in an unfair way.
Comcast was trying to make the argument that Netflix was unduly routing traffic unto Comcast's network... but all of that traffic were packets that had been specifically requested by Comcast customers. It's not Cogent's fault that Comcast's customers have asymmetric traffic patterns.
I do agree that Comcast was stretching the argument, but I'm pretty convinced that it was to try to gain business leverage against Cogent, rather than to try to justify jacking up prices for their customers who watched Netflix. I'm not arguing that Comcast's actions were particularly noble or righteous, but rather, that they were fighting with Cogent, not with Netflix.
> Comcast was trying to make the argument that Netflix was unduly routing traffic unto Comcast's network... but all of that traffic were packets that had been specifically requested by Comcast customers. It's not Cogent's fault that Comcast's customers have asymmetric traffic patterns.
Comcast was arguing that Cogent was unduly routing traffic onto Comcast's network (the majority of which happened to be Netflix traffic). You're certainly right that it's not Cogent's fault that Comcast's customers have asymmetric traffic patterns, but it is Cogent's fault that they've been historically abusive to their peers on the pretext of the traditional agreements built around symmetric exchange. I think that Comcast just got fed up with Cogent throwing its weight around and saw an opportunity in Netflix's huge amounts of traffic to force Cogent into terms more favorable to Comcast.
(It's pretty clear that Comcast won that round, IMO - but the loser was Cogent, not Netflix.)
The idea that settlement-free peering always assumes symmetric flows is a common myth. Nobody expects peering with a residential ISP to have symmetric traffic because that doesn't make sense, of course the flows are going to be overwhelmingly towards the residential side of the link.
Back in 2014 when all this was going on Level 3 published an unusually scathing series of blog posts where they called out residential ISPs for deliberately allowing their exchange links to saturate in order to extort extra payments from Level 3 and their customers.
Twitter gave the police information about the phone number which registered the account that sent the seizure-triggering gif
AT&T gave the police information that is was a Tracfone prepaid account with an associated toll record that was an iphone
Apple gave them access to his cloud account which had all the incriminating details needed including email / picture of him with his drivers license and data about the victim
I'm sure Dropbox is going to get a lot of flak for this. 2FA based on the provider that they use may not have been cheap. Authy is $0.09 an auth, if you integrate with Twilio, you get SMS charges that vary on price based on country / provider.
The easiest/cheapest solution is to roll your own TOTP and build an app. This is useful for web, but may be pointless on mobile (if the mobile device is unlocked, then you have access to the TOTP app or SMS).
Business people probably looked at the cost per user and couldn't offer it at a lower rate.
You wouldn't need to roll your own app. Just use the Microsoft Authenticator app or the Google Authenticator app, they're the same thing and don't require a direct connection to the user account. Lots of articles on the net on how to accomplish this kind of thing for $0 in extra services.
Isn't 2fa by sms bad though? You hear a new case almost every week of someone whose telco was socially engineered to gain access to their phone number linked 2fa/account recovery.
Bad is relative, it is bad compared to other more secure methods. But if you can't guarantee that your users have a smartphone, SMS is still a needed option.
It doesn't really matter where you start, as long as you can relate to the product and its customers. I've seen great PM from every beginning. My beginning was a normal comp sci background -> dev -> customer success manager (any support role is a great segway into product management role) -> PM. Having managed many PMs, it boils down to this:
Can you be an advocate for your customer for your product, regardless of intercompany demands?
Can you communicate your vision for what needs to be built effectively across the whole company?
Those are the two main skills that I try to distil for any PM that I hire. There is a 3rd which I call the auxiliary skill (these can be taught easily, hence auxiliary).
How do you validate your assumptions, remove cognitive biases to come to the best decision about the priority on what should be built when?
And a fourth, which comes down to background and personality:
Can you be a swiss army knife and help wherever the team needs you?
The product I currently manage is a developer tool, so taking a look at an example based on the 4 points:
1. Can you relate to developer pain points, market problems with identity, create great developer experience and understand where there are holes in the current product?
2. How can you use the tools at your disposal to communicate what we need to build to the engineering team, marketing, and executives. Technical and non-technical folks alike, even for a technical product that is sold to devs.
3. How can you manage feedback / signals from sales, developer evangelism, customer asks, and visionaries to create a roadmap
4. Demonstrate how you have needed to step out of your comfort zone to get the job done.
When interviewing, having a developer background is a must (but it is only a must because my product is currently catering to the developer persona), but replace a developer product with a dental product that is sold to dentists. That hiring manager is going to want someone that more than likely understands dentists and their pain points that the software is currently solving for. They could come from, office manager, dentist moving to software (it happens), someone from the insurance industry... you see the point.
Hope this helps, I'm always happy to help and advise. Snag my twitter handle from the profile and shoot me a DM.
Are you a small time supplier, and want a major retailer to integrate with you over API? good luck. The decision really isn't yours, if you want to get paid, you integrate.
I think the reality is that most developers would rather use an JSON API instead of EDI. EDI is sometimes talked about as just X12 / EDIFACT, but the protocol is baked in as well, which causes more headache (who wants to build an EDI stack?). X12 was built during a time where VANs probably connectivity, and caused per character, so everything was positional based and inferred. Modern APIs are descriptive, and easier to use.
(fd: I work for Orderful, a company that provides an API and then translates it to EDI so you can easily work with any trading partner)