The google/t-mobilve video is a good perspective on the problem: The transparent proxies where deployed for a reason. Why for example could the same throughput goals not easier be achieved with explicit proxies, eg: http proxies ? Some work from ART that could fix this ?
Given how we know that transparency is a problem, why not try to solve that by offering options for explicitly visible proxies at transport layer, eg: with PLUS. Could easily (IMHO) include diagnostics, ot-in or opt-out options. Use case for example: do not use the proxy when the app thinks it can do it better itself. Btw: Diagnostics isn't only bad with most current transparent middleboxes It eqully worse because of the end-to-end principle. Whats my best option to localize throughput problems on my oh so wonderfully transparent internet path - so i can complain to the right ISP ? Pathchar ??? Justs to keep things in perspective.. On Fri, Aug 05, 2016 at 01:49:26PM -0700, Yuchung Cheng wrote: > FWIW Tmobile and Google talked about an experiment to bypass Tmo proxies on > YouTube traffic in the Velocity conference. It was recorded at > https://www.youtube.com/watch?v=G_SMCYu7qSw > (For the impatient, you can skip the first 11 mintues) On Fri, Aug 05, 2016 at 01:55:58PM -0700, Joe Touch wrote: > On 8/5/2016 1:21 PM, Fred Baker (fred) wrote: > > > >> On Jul 27, 2016, at 11:51 AM, Joe Touch <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Sure - my point is that the term "transparent proxy" is common, and > >> ALL such animals break TCP semantics *by design*. > > > > From my perspective (which is always right), the right way to fix > > these middle boxes is to let users have trouble with them and complain. > I agree, but users don't always know where to direct their ire. > > > Someone that installs idiot-ware deserves the cost of fixing it. > > They deserve many costs - the cost of lost revenue while they use it, > the cost of fixing it, etc. > > The trick (as always) is to put the pain where the power lies to solve > the problem. > > Joe
