[e2e] It's all my fault

[Jon Crowcroft]

exactly - the benefits of long haul provider selection are clear

note also source route is not necessarily spiral routing (as christian huiteman
said) - BGP already results in longer routes than "optimal" in the user sense,
and for the same reasons that users want to choose different carriers in phone
nets (price, performance, mileage deals), there are sound business reasons for
users to ask for different IP segements to there paths - see the MIT RON papers
to see how this can be done with overlays to improve resilience.

current IP routing is not optimal since it is about expressing ISP business
relationshios, not user preferences - the balance has tipped way too far - all
the "business case" arguments you hear in favour or against his or that IP
technologiy are almost always about ISPs or router vendors rather than users - if
the people making these arguments actually were on the sharp end of business,
they'd be out of it pretty soon:)

of course optimality (and rationality) have had little to do with IP design since
the late 1980s... :-)


on DDoS prevention/mitigation and ip (loose) source routing: since we have had
ddos attacxks for some time without LSR, what is the actual evidence that LSR
makes it 
i) harder to mitgate
ii) easier to find the source?

given the source is a traffic generator (and often distributed over a botnet)
the ways to find it and mitgate it are based on detecting an unusual set of
destiantions and inter-transmission intervals to a wider than usual set of IP
destinations, NEAR THE SOURCE, not at the sink where it is already too late

whether the traffic goes via a "3rd party" (e.g. gosh, a router:), 
or taxi, plane, satellite, mars lander, or via your pet cat's radio
in her golf ball is irrelevant - if you're looking there, you've already missed the bus.

In missive <20070515114552.7f8d0f4c at garlique.algebras.org>, George Michaelson typed:

 >>
 >>Did phone systems have toll-select and explicit long-haul select before
 >>IP networks? manually, I would argue yes. morally, I think asking the
 >>operator to connect your call via a specific path is loose-source..
 >>
 >>(for quite a while, it paid to know the fax-attuned IDD prefix to hop
 >>off australia. the QDU's on the line were lower, and it took less
 >>traffic. It seemed to be easier to get round the IDD jogjam at
 >>christmas if you knew the prefix)
 >>
 >>back in the JANET coloured book day.. applications like mail had to
 >>have loose-source equivalent because they were lower-stack agile. the
 >>transforms on mail represented paths into the transports along the way
 >>were (to say the least) amusing, and the potential for mish-mash (ARPA
 >>to uk/janet to ARPA to uucp to DECNET to ..) fantastic. Yes, Peter
 >>Honeyman made life easier, in the sense that an offline pre-compute of
 >>the flatness to user at host worked. Sometimes I wish BGP was offline, and
 >>we had defined statics in the DFZ. -Geographics could work in that
 >>model, but I don't think you much want that raised here..
 >>
 >>SERC mail was pretty flat, but I believe you could specific explicit
 >>paths. I don't think they mapped cleanly to X.25 hops, but my memory
 >>fades. (mostly, I (and I think everyone else) used X.25 PAD to hop onto
 >>the end system, and logged in to mail local users. I certainly did this
 >>to EMAS at Edinburgh from YKXA on SERCnet. But I do recall an explicit
 >>path notation in a Dec-10 inter-site mailsystem, and in the Jacob Palme
 >>news system which pre-dated UUCP/USENET as far as I know, on Tops-10)
 >>And I think several people independently (re)implemented mail level
 >>explicit path hacks into local mail transports. over and over again.
 >>
 >>These kinds of things meant that the clue-density for the userbase was
 >>higher, with respect to what the likely behaviours were for having
 >>explicit control of the lower level packet routing: mentally, you
 >>already had to know this kind of connectivity anyway.
 >>
 >>I only used the telnet @path options once myself. But I know of
 >>somebody who used it to force a path into a recalcitrant network when
 >>his interior route died on him. This was in the mod 1990s so its within
 >>living memory that people understood and expected to use this kind of
 >>thing, in extremis.
 >>
 >>I was very dissapointed when I discovered how small ATM network
 >>addressing was. Amazing to see a 19th Century circuit switched model
 >>with tiny numberspace for endpoint addressing, and lowly engineers in
 >>boilersuits polishing the shiny brass knobs on crossbar switching
 >>between elements in the path. You really DO know that its a specific
 >>lightpath sometimes.
 >>
 >>Should a network prevent people from directing packet-paths? Why?
 >>Should users expect to be able to direct packet paths? Why? 
 >>
 >>cui bono?
 >>
 >>Beerworthy. But pragmatically, we've taken ourselves to a world where
 >>the dialogue, and the outcome are divorced from this discussion.
 >>
 >>
 >>-G

 cheers

   jon