[e2e] SLOW TCP flashmob meeting

[Jon Crowcroft]

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 environments.

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.

j.
p.s.
I'm resending this as the last post got trapped by the "press annoucenment or CfP spam"
filter on the e2e interest list:-)