Hi Jason, thanks for giving some perspective.
> On Sep 28, 2023, at 19:10, Livingood, Jason <jason_living...@comcast.com> > wrote: > > On 9/28/23, 02:25, "Bloat on behalf of Sebastian Moeller via Bloat" > <bloat-boun...@lists.bufferbloat.net > <mailto:bloat-boun...@lists.bufferbloat.net> on behalf of > bloat@lists.bufferbloat.net <mailto:bloat@lists.bufferbloat.net>> wrote: >> But the core issue IMHO really was an economic one, the over-subscription >> ratios that worked before torrenting simply did not cut it any more in an >> environment when customers actually tried to use their contracted access >> rates "quantitatively". > > It was more complicated than that. At least in cable networks it came at the > end of single channel DOCSIS 2.0 devices, as cable upgraded to channel > bonding in DOCSIS 3.0 - which to your point brought dramatic increases in > capacity. That was happening at the same time P2P was becoming popular. On > the other hand, customers were congesting their own connections pretty > pervasively - trying to use VoIP while their P2P client was active. At the > time the P2P protocol tended to be pretty aggressive and smothered real-time > apps (if you gave the client 1 Mbps US it would use it, if 10 Mbps - used > that 100% as well, 25 Mbps - same, etc.). [SM] Thanks! I will adjust my position ("mainly too much oversubscription") to give at least equal weight to self-congesation by overly aggressive new application types, simply because you have likely seen internal data demonstrating that and I fully believe your summary. > The answer ended up being a mix of more capacity, apps being more responsive > to other LAN demands, and then advancements in congestion control & queuing. > But there were many customers who were basically self-congesting w/P2P and > VoIP running in their home. [SM] So is it fair to say that the problam was also caused by a rapidly change in usage profiles or was that the smaller problem, if at all a problem? > >> but this is why e.g. my bit torrent could affect your VoIP, simply by >> pushing the whole segment into upload capacity congestion... (ISPs in theory >> could fix this by plain old QoS engineering, but the issue at hand was with >> a non-ISP VoIP/SIP service and there QoS becomes tricky if the ISP as these >> packets need to be identified in a way that is not game-able**) > > Sure - for their own (nascent & small scale) digital voice products. But to > 3rd party VoIP - no one then was really doing inter-domain DSCP marking > end-to-end (still are not). The non-ISP offering here was the big driver of > consumer complaints. [SM] I accept that this was not a clear and simple solution, just that it would have been technically possible (just infeasible as it likely would have required multiple SLA's between all pairs of partner's to "secure" the full path? >> ****) This is not to diss the press, they are doing what they are supposed >> to do, but it just shows that active regulation is a tricky business, and a >> light touch typically "looks better" (even though I see no real evidence it >> actually works better). > > It's not made easier in the US where one can strongly support formal national > NN rules but be against putting it under Title-II regulation vs. Title-I. > IANAL so cannot properly explain the nuances. [SM] Same here, the legal nuances are lost on me as well, especially about noticeably different legal systems like the US' compared to home (were I am also not a legal expert, but were I have read a few laws and regulations). Also I assume that the whole issue would look quite different from an ISP perspective, nobody likes having their option space restricted for the acts of a few bad apples... > Ultimately legislation is the best solution, as this will just be in the > courts for years, but our US Congress is not the most functional body these > days and people have tried to do legislation for many years. [SM] Proper legislation has the advantage of offering a fair playing field for all ISPs, and after the unavoidable initial tire kicking by the courts will hopefully be robust and reliable. > > Jason > _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
