It's nearly impossible to obfuscate a protocol to work around filtering.
You'd want to look like some other protocol and you want that protocol be encrypted by default. Otherwise yours will get fingerprinted via the deep packet inspection.
The most obvious choice is to run your protocol over TLS. But then they can just throttle long-lived bulky TLS connections where neither side is on 443.
You can then require the responding side be on 443 (which is already a big hassle), but they will then throttle down TLS connections towards residential IPs or throttle them down cumulatively, as a group.
Other choices here are OpenVPN, WireGuard and, possibly, IPsec. But, again, it will come down to defeating the throttling of multiple inbound bulky connections of the same type, which is doubly hard to bypass if you are on a residential IP and your ISP is really bent on throttling.
Any successful obfuscation technique is short-lived, so it has no place in the protocol itself. Instead it should be delegated to a transport layer and the clients should be coded to support BT tunneling over X or over Y.
This is all true. The best way to make your application work now matter what filtering is in place is to disguise it as something which the ISP has to make work in order to get customers.
Fundamentally, nothing has the same characteristics as BitTorrent - almost nothing has the same high uplink requirements, which is an absolute signature of BitTorrent traffic.
Oh, also some of the shaping is implicit, not explicit. Most home internet connections are asymmetric - they dedicate more channels to downlink than uplink.
The problem is that most residential users don't care about upload speed.
This allows ISPs to throttle uploads with very low risk of pissing off the bulk of their customer base when their detection algorithm gives a false positive.
I doubt working from home changes all that much. The pattern for most office workloads is still almost all pull. More VoIP is a not insignificant change but it still isn't the same kind of traffic that torrents put down.
Upload is pretty heavy with video chat. However, it's relatively easy to detect from an ISP's standpoint. Almost all the upload will be to a single IP address of a known video conference provider (Zoom, teams, whatever google is doing now, facebook, etc).
Not a viable solution in the US. Most ISPs operate on exclusivity agreements, and like 90% of users effectively have only a single choice of ISP for internet of a reasonable speed.
A better solution would be to have rules to make that kind of throttling illegal, but we've seen how that played out.
> 90% of users effectively have only a single choice of ISP for internet of a reasonable speed
Which is mainly because we have privatized roads here in the USA.
Yes, you read that right. The "gold standard" is underground fiber, which lies in the public right-of-way yet is 100% privately owned with no "duty to serve" like the electric utility has. Oftentimes the fiber owner doesn't even have to dig up the dirt -- if they lay fiber along a newly built highway the government does all the digging for them (to create the roadside drainage ditch). The phone company just unreels a spool of armored OS2 into the ditch and hey, it's Miller Time.
Until privatized right-of-way stops we will continue to get screwed.
[*] Transcontinental railroad right-of-ways are the exception to the above, but there's only four of them. And, frankly, that land was privatized through outright fraud. Read the book _Railroaded_ sometime, it's shocking.
You'd want to look like some other protocol and you want that protocol be encrypted by default. Otherwise yours will get fingerprinted via the deep packet inspection.
The most obvious choice is to run your protocol over TLS. But then they can just throttle long-lived bulky TLS connections where neither side is on 443.
You can then require the responding side be on 443 (which is already a big hassle), but they will then throttle down TLS connections towards residential IPs or throttle them down cumulatively, as a group.
Other choices here are OpenVPN, WireGuard and, possibly, IPsec. But, again, it will come down to defeating the throttling of multiple inbound bulky connections of the same type, which is doubly hard to bypass if you are on a residential IP and your ISP is really bent on throttling.
Any successful obfuscation technique is short-lived, so it has no place in the protocol itself. Instead it should be delegated to a transport layer and the clients should be coded to support BT tunneling over X or over Y.