[e2e] YNT: A Question on the TCP handoff

[Jon Crowcroft]

In missive <Pine.GSO.4.50.0512102317590.24358-100000 at argos.ee.surrey.ac.uk>, Ll
oyd Wood typed:

 >>On Sat, 10 Dec 2005, Jon Crowcroft wrote:
 
 >>So, what's the point in introducing more than the one necessary path
 >>change, since the high-rate traffic will be disrupted at each and
 >>every routing change of path, no matter how small, while sufficiently
 >>low-rate traffic won't even notice the intermediate steps you're
 >>introducing and see only the first and final paths/routes as it did
 >>before?

there's an awful lot of assumptions about the network in that
paragraph - and your thesis makes assumptions about the network that
are different than
i) the terrestrial net we are talking about
ii) the lifely future topologies of the internet.
iii) the traffic model

 >>See:
 >>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/PhD-thesis/
 >>figures 2.24 and 2.25, pp.49-50 (pdf pages 71 and 72)
 >>for a worked example of this.

 >>I see no point to disrupting high-rate traffic with a cascade of
 >>multiple (and larger than one hop) path changes and more jitter
 >>variations, while low-rate traffic won't notice what you're
 >>introducing if you're propagating the gradual changes on a reasonable
 >>timescale. I'm afraid your suggestion isn't practical.

I didnt spell out a concrete algorith - the one I have in mind
does this as a +side effect+ of the way route computation and update
are performed and has low overhead

 >>> also, it doesn't need any tcp state in the routers to do it - its
 >>> just a change to the way we get from the result of one dijkstra or
 >>> one BGP outcome, to another -its like a generalised version of
 >>> crankback, then crankforward, but with live traffic
 
 >>so you're moving BGP updates around as well?

not BGP as we know it today, jim - this is _research_

 >>> an added benefit os such a routing algorithm would be that under
 >>> churn, or heavy flapping, the route performance as perceived by
 >>> end2end users would be relatively stable.
 
 >>your suggested algorithm _introduces more more churn and more
 >>flapping_ -- and thus more jitter to high-rate traffic.

not more flapping - no - flapping is intermittent and oscilliatory - i
produce piecewise improvements

 >>Deliberately introducing disruption to gain stability only works if
 >>you're really really good at control theory and have a tractable
 >>problem space. Internetworking/comp. sci. people rarely have the
 >>second, and have generally never been exposed to learning the first.

- so i guess my physics (which includes control theory) was
irrelevant then:)  - or do you mewan that most people on this list
are compscis? many networking people  have EE degrees which have far
more control theory actually from year 1...(oh, btw, i taught courses
in EE for >10 years, so i was exposed to a lot of it -)

if we are to be _polite_ for a change,
problem actually is that we need to use BOTH algorithmics AND control
theory, and that requires one to cross a couple of disciplines, which
can be done if you have the math, and th patience to read a few books
and go on some courses and try out a few things 

 >>(I mean, "crankforward"? It's a googlewhack.)
 
yep

 >>> what would such an algorithm look like? well, its a bit like the
 >>> opposite of a link disjoint load balancing routing algorithm - i
 >>> leave it as an excercise for the reader to come up with a
 >>> modification to OSPF and BGP to achieve such a goal as there isn't
 >>> space between these two pixels to write it down......
 
 >>Fermat had the good grace to be right.

if you want to be pedantic,
we don't know that actually - we know that there was a proof, but we
do not know if he really had one or that it was right. just that he
asserted it. read the book.
 >>>
 >>
 >>plus I reformatted all jon's crazy linewrapping without grumbling
 >>about it -- Detlef, be liberal in what you receive, conservative in
 >>what you send. Alper and other Outlook users, take note of advice on:
 >>http://www.ee.surrey.ac.uk/Personal/L.Wood/outlook/
 >>
 >><http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at eim.surrey.ac.uk>

 cheers

   jon