[e2e] SLOW TCP flashmob meeting

David P. Reed dpreed at reed.com
Mon Aug 11 05:07:49 PDT 2003

We don't even need to modify the Linux kernel.   You can add the 
modification to Linux, Windows, and even OS/360 quite simply at the 
hardware level by merely unsoldering one of the pins on your RJ45 connector 
and inserting a diode there.   Perhaps it should be called 802.2slow, but 
the modification works like a charm.

At 06:38 PM 8/10/2003 +0100, Jon Crowcroft wrote:
>we'd like for anyone (especially science writers and journalists and final 
>year project
>students) who is free at 23.59 on the sunday 24th august (just before 
>sigcomm) to come
>along to a special announcement meeting on SLOW TCP
>SLOW TCP is a departure for end2end performance - where most (esp. US incl 
>DARPA) research
>on protocols has gone for bigger networks (long fat pipes) and faster 
>protocols (FAST, etc),
>we decided that there was room at the bottom for a TCP that went slower 
>than any other
>while being compliant with all relevant RFCs, SLOW (Scalably Low Overhead 
>Windowless) TCP
>is  designed to work in environments with very low power (see the sigcomm 
>paper on greening
>the internet) since it takes a lot less to get a SLOW TCP flow through the 
>net than a fast
>one, making this ideal for sensor networks and other resource constrained 
>Unlike the high end, where special equipment (e.g. DAG boards) is needed 
>to stand a chance
>of capturing the packets, SLOW TCP is so slow that we need even more 
>special equipment - in
>fact, I am waiting for those folks with the million gallon tanks of 
>drycleaning fluid to
>get back to me as I think SLOW TCP Packet events will be equally both as 
>feint and rare and
>lacking in gravity.
>SLOW TCP is easily implemented - you just need to find the right 23 lines 
>in your linux
>kernel to delete, and voila, working, compliant SLOW
>Added advantages of SLOW TCP are that you can get many more flows into a 
>fat pipe so
>aggregation techniques obey the laws of large numbers better. You almost 
>NEVER incur a
>congestion charge. SLOW TCP flows can still be bundled to make normal 
>TCP  - we are working
>on mechanisms to create superbundles of SLOW TCP (e.g. 10^9 SLOW make one 
>FAST on todays
>GRID netherlight/starlight express enabled routes).
>We havnt published any papers on SLOW TCP for a variety of reasons
>i) we havnt got the carbon tetrachloride yet, so the measurements arent 
>there to back up
>the NS2 simulations
>2) linux hasnt stayed up long enough (11 years) for the NS2 simulations to 
>finish with
>plausible results
>3) its hard to convince people that papers with TCP in the title, and only 
>code deletion
>can really be worth publishing without a lot of math, but we are not good 
>enough with latex
>yet to get the equation numbering high enough
>4) our CEO^H^H^H professor says we dont need a paper to get lots of VC 
>money^H^H^H^ phd
>The neat thing about SLOW TCP is that it gets rid of all that weird code 
>for sequence
>number wrapping and scalable window options and SACK and stuff - we never 
>have ore than one
>outstanding packet (note, though, it is outstandingly long lived). It 
>reduces buffering
>overheads in the send and receive side system. there's even evidence that 
>it calms the
>nerves of people used to seeing fast, then inexplicably (probably route 
>change induced)
>congestion backoff - since its always slow, SLOW is good karma.
>We hope to submit a report loosely base on this during the OO session at 
>SIGCOMM, although
>its possible the OO session chairs will see sense at the last minute 
>and  ask us to leave
>the country.
>Our first demo of SLOW TCP has been for reliable delivery of keys over a 
>quantum crypto
>link - at least we think so - the cat who ran the experiment
>was not so convinced, well, at least our cat.
>the other end's cat was comme ci, comme ca, little bit high, little bit low,
>at least thats what he said before he died.
>oh well, at least no animals were provably harmed during this experiment.
>Anyhow, I hope at least Cory Doctorow or maybe Neal Stephenson will show 
>up so we can ask
>them to give us an autograph, and maybe even try sending secure e-mail 
>over a SLOW link -
>after all if it was good enough for the queen in 1976, it ought to be good 
>enough for them.
>I'm resending this as the last post got trapped by the "press annoucenment 
>or CfP spam"
>filter on the e2e interest list:-)

More information about the end2end-interest mailing list