From Jon.Crowcroft at cl.cam.ac.uk Thu Aug 1 02:38:38 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 01 Aug 2013 10:38:38 +0100 Subject: [e2e] TCP "experiments" In-Reply-To: <2A89DA46-85CA-4261-AF2E-D15DE4222ED4@tlc.polito.it> References: <51EC4468.1010105@web.de> <7C62F84D-A881-4609-ABB9-9E700F3896FF@isi.edu> <8C48B86A895913448548E6D15DA7553B94661D@xmb-rcd-x09.cisco.com> <51F191D0.6030807@isi.edu> <51F19708.3050206@isi.edu> <51F2B580.9040703@isi.edu> <1CCA5689-7C66-4F43-856B-F3CC8E0B6548@isi.edu> <51F6A578.5010000@isi.edu> <51F6F523.6060107@isi.edu> <2EBB07CA-C011-4DC4-AACD-5A9D959C59D7@isi.edu> <2A89DA46-85CA-4261-AF2E-D15DE4222ED4@tlc.polito.it> Message-ID: yes, fairness is a key idea which has to be linked with some accountable entity here's an interesting relevant paper (i think:) http://www.sigcomm.org/ccr/papers/2008/January/1341431.1341434 In missive <2A89DA46-85CA-4261-AF2E-D15DE4222ED4 at tlc.polito.it>, Marco Mellia typed: >>If you want an example where a change would be not "fair", you can = >>consider YouTube. >>Now they start to use more than one TCP connection to serve the video. >>This avoids that the application gets stuck because the TCP connection = >>gets stuck. >>In case of competing traffic (and congestion), YouTube client will = >>download in parallel from multiple connections (we have seen up to 5). >>Thus sharing capacity is not fair against other concurrent traffic. >>You may say that Video is not best effort, so why not. >>But in a scenario where you use YouTube and I use MyTube, you'll see, = >>and I'll not see :( >>You are more aggressive, and get a larger share of capacity. >> >>Same for TCP initial window. You use 10, I use 2. You are more = >>aggressive. I suffer from additional losses/delay because of you (in = >>case we share the same link). >> >>As said, weighting the pros against the cons is not easy. >> >>Anyway, I found it funny that we can discuss this forever. But actually = >>no one has the right/power/control of imposing anything on the Internet.=20= >> >>Basically, it's a perfect anarchy, where everyone is allowed to = >>do/deploy whatever he thinks it's good for him.=20 >>I push more, I get more. I don't care if you get hurt=85 >>Would be nice to have a system where some judge can say that you are = >>pushing too much, and provide a punishment for you. But this seems quite = >>impossible here=85 >> >>Ciao >>M >> >> >> >>> In missive , Marco = >>Mellia typed: >>>=20 >>>>> Jon, >>>>>=20 >>>>> I think no one is saying that big companies are doing dumb things. = >>It's =3D >>>>> just that the Internet is a really shared infrastructure. >>>>> Unless resources are infinite (which may be actually the case for = >>Google =3D >>>>> :)), gaining something somewhere comes at the expenses of loosing =3D >>>>> something else somewhere else. >>>>>=20 >>>>> Considering TCP, it is easy to show that "I can gain". It is much = >>harder =3D >>>>> to show "who else is loosing". >>>>> And weighting the plus and the minus is even more complicated. >>>>>=20 >>>>> M >>>>>=20 >>>>>=20 >>>>> --=3D20 >>>>> Marco Mellia - Assistant Professor >>>>> Dipartimento di Elettronica e Telecomunicazioni >>>>> Politecnico di Torino >>>>> Corso Duca Degli Abruzzi 24 >>>>> 10129 - Torino - IT >>>>> Tel: +39-011-090-4173 >>>>> Cel: +39-331-6714789 >>>>> Skype: mgmellia >>>>> Home page: http://www.tlc-networks.polito.it/mellia >>>>>=20 >>>>> On Jul 30, 2013, at 1:34 AM, Jon Crowcroft = >> =3D >>>>> wrote: >>>>>=20 >>>>>> the nice thing about a lot of the big cloud/web service outfits=3D20 >>>>>> is that they run a huge _range_ of applications so a point = >>solution=3D20 >>>>>> tcp optimised for just one thing that=3D20 >>>>>> harmed the common case uses of TCP would be ruled out -=3D20 >>>>>> =3D20 >>>>>> if you think about the mix of map/reduce,=3D20 >>>>>> video streaming, social net, searches, gmail, gfs, google docs, etc = >>=3D >>>>> etc=3D20 >>>>>> (and similar mixes for microsoft bing + hotmail + azure etc;=3D20 >>>>>> and similar for apple iCloud, appstore, and similar for, >>>>>> oh, i dunno, maybe even facebook),=3D20 >>>>>> then I doubt very much we'd see them do something >>>>>> as narrowly dumb as people seem to imply here=3D20 >>>>>> (or deploy someone else's dumb narrow hack either).... >>>>>> =3D20 >>>>>> as for impact between different cloud/web service providers >>>>>> (e.g. google being smart enough to optimise a TCP hack for all that = >>=3D >>>>> stuff >>>>>> but still harm Amazon's traffic for book/cd buying, EC2, cloud = >>music =3D >>>>> player >>>>>> etc etc, that would be incredibly ingeneiously dumb,=3D20 >>>>>> but also unlikely, since a major google's revenue depends on=3D20 >>>>>> people finding stuff on _other servers,=3D20 >>>>>> and finding those other services useful,=3D20 >>>>>> so it would be kind of silly to auction advert space to the highest = >>=3D >>>>> bidder=3D20 >>>>>> iand deliver those adverts in a way that broke the advertised =3D >>>>> things.... >>>>>> =3D20 >>>>>> [I suppose you could deliver adverts that broke TCP services to >>>>>> servers that hadn't paid you to advertise them - that'd be pretty >>>>>> super duper whacky type of cyberwarfare game some folks at the NSA >>>>>> probably have fun thinking up..... >>>>>> =3D20 >>>>>> maybe Huawei could deploy some DPI-based filter to harm succesful =3D= >> >>>>> businesses only >>>>>> so as to bring down the whole capitalist imperialist western =3D >>>>> civilisation....oh no, >>>>>> wait, they need our net to work so they can sell us their = >>routers... >>>>>> =3D20 >>>>>> In missive <2EBB07CA-C011-4DC4-AACD-5A9D959C59D7 at isi.edu>, Joe = >>Touch =3D >>>>> typed: >>>>>> =3D20 >>>>>>>> =3D20 >>>>>>>> =3D20 >>>>>>>> On Jul 29, 2013, at 11:14 PM, Jon Crowcroft =3D >>>>> wro=3D3D >>>>>>>> te: >>>>>>>> =3D20 >>>>>>>>> google have extremely good instrumentation - >>>>>>>> =3D20 >>>>>>>> They can now see how my PC talks to amazon.com now? >>>>>>>> =3D20 >>>>>>>>> their shareholders would get upset if they deployed things that = >>=3D >>>>> broke >>>>>>>>> the world badly - >>>>>>>> =3D20 >>>>>>>> Even if they made Google 0.01% faster? And increased ad revenue = >>as a =3D >>>>> result?=3D3D >>>>>>>> And stock value or dividends? >>>>>>>> =3D20 >>>>>>>>> that's the NSA's job. >>>>>>>> =3D20 >>>>>>>> Sound like you're referring to my first point above :-) >>>>>>>> =3D20 >>>>>>>> Joe=3D3D20 >>>>>>>> =3D20 >>>>>> =3D20 >>>>>> cheers >>>>>> =3D20 >>>>>> jon >>>>>> =3D20 >>>>>=20 >>>=20 >>> cheers >>>=20 >>> jon >>>=20 >> cheers jon From mellia at tlc.polito.it Thu Aug 1 10:37:54 2013 From: mellia at tlc.polito.it (Marco Mellia) Date: Thu, 1 Aug 2013 10:37:54 -0700 Subject: [e2e] TCP "experiments" In-Reply-To: <1375372357.279315948@apps.rackspace.com> References: <51EC4468.1010105@web.de> <7C62F84D-A881-4609-ABB9-9E700F3896FF@isi.edu> <8C48B86A895913448548E6D15DA7553B94661D@xmb-rcd-x09.cisco.com> <51F191D0.6030807@isi.edu> <51F19708.3050206@isi.edu> <51F2B580.9040703@isi.edu> <1CCA5689-7C66-4F43-856B-F3CC8E0B6548@isi.edu> <51F6A578.5010000@isi.edu> <51F6F523.6060107@isi.edu> <2EBB07CA-C011-4DC4-AACD-5A9D959C59D7@isi.edu> <2 A89DA46-85CA-4261-AF2E-D15DE4222ED4@tlc.polito.it> <1375372357.279315948@apps.rackspace.com> Message-ID: <475424F2-3F53-4FBD-9ED9-FC3617CDE07D@tlc.polito.it> > Two observations. > > 1) YouTube usage needs the same data rate, whether its content is spread over multiple TCP connections or not. It's hardly obvious that there is a significant problem here. Van Jacobson and I talk about the rate-of-convergence to a False, since YouTube uses adaptive streaming? So being more aggressive allows you to get more capacity => switch to higher quality etc. > "fair sharing" of whatever bottleneck resource there is. Rate-of-convergence is orthogonal to fairness and ideally the faster the rate of convergence the less impact congestion has. So I wish that others would model/measure/explore this behavior. Though obviously, the real goal of a network is to rarely have any bottleneck in the network that interferes with user traffic, assuming the users are paying for service. Good point. When YouTube will switch by default to HD video, more than doubling the bandwidth, who is going to pay for the additional capacity? End-users are really not likely to give a dime more to the ISP... > 2) Anarchy is the wrong name. In an anarchy, *individuals* act independently in their own interest. In a network, communication requires cooperation. Cooperation is at least pairwise, and generally is much higher-dimensional (or "groupy"). That is, large subsets need to agree on a protocol strategy among themselves to succeed in communicating. This *cannot* be anarchy. Maybe it is "multi-archy" rather than hierarchy. However, it is the case that if you choose your own personal congestion management protocol, you are likely not to be able to communicate, and certainly will have difficulty sharing the network with others. Ok, you don't like anarchy? But I don't get the "if you choose a different congestion management protocol, you are likely not to be able to communicate". It seems to me that congestion control, and parameter setting (e.g., initial window, initial timeout, back off factor, etc) can be changed almost freely without breaking the communication... > The forcing function of cooperation (call it Metcalfe's Law or Reed's Law or whatever the heck you want to call it) drives all participants in the Internet, and all of their suppliers, to develop common approaches. The ones that work well, win. Evolution of the Internet (either by design or by accident) generally drives toward effective sharing. 100% agree if you are saying that when A changes something so it get a better service, than B and C and D will sooner of later implement the same change. The problem is when A has already a predominant role in the market, and keep rolling out modifications that improves its service (at the expense of someone else eventually). This could lead to monopoly. Not sure I'd like this. > This is ignored by most professors of communications networks, and I doubt is mentioned in most textbooks. Yet it is staring us in the face. Economic principles are not part of the OSI model :) Ciao M