Bill,
On 2009-01-03 07:16, William Herrin wrote:
> On Thu, Jan 1, 2009 at 2:43 PM, Brian E Carpenter
> <[email protected]> wrote:
>> On 2009-01-02 05:37, William Herrin wrote:
>>> I insist on me being able to
>>> satisfactorily explain how a particular approach would reduce the need
>>> or demand for core routing slots.
>> Slide 15 in
>> http://www.cs.auckland.ac.nz/~brian/RRG0708.pdf
>
>
> Thanks Brian.
>
> I follow how slide 15 achieves reliable multihoming given two constraints:
>
> 1. System contains client machines. If it contains servers, they are
> limited to those protocols which have a thoroughly defined layer-7
> multihoming process, such as SMTP.
Yes, layer 7 has to be able to cope with this.
> 2. Loss of session during a multihoming event deemed acceptable.
Yes, which implies that layer 7 transactions must have intrinsic
robustness (not a new idea in the transaction processing business).
>
> I accept the proposition that some significant fraction of the
> multihoming demand could be satisfied with a system meeting criteria
> #2. Given a satisfactorily low rate of multihoming events, a pizza
> joint is happy as long as the SIP phones immediately re-establish and
> the web users can get the page by hitting reload.
>
> I accept that slide 15 offers qualitatively different multihoming
> versus slide 16 in that slide 15 does not require hosts to deal with
> routing constructs with which they are not presently familiar. When
> fleshed out to provide a complete multihoming solution, slide 16
> evolves into strategy B.
Correct.
>
> Question:
>
> What's the cause to believe that systems meeting criteria #1 represent
> a more-than-negligible portion of the multihoming demand that is
> either unserved or served by BGP?
Well, I believe that all successful transaction-style layer 7s meet
this and have done since the earliest days of on-line transaction
processing. And I think there's a reason why the large business systems
of today are built on top of web services namespaces or similar, which
form an abstraction layer that basically hides *everything* we're talking
about here. But, indeed, anything that rides directly on the socket API
is exposed (a bit less so with getaddrinfo than gethostbyname, however).
>
>
> You may choose to dispute criteria #1. Before you do, I remind you
> that the primary API for access to the DNS (gethostbyname) is
> irretrievably defective, at least as it pertains to providing an
> ephemeral GUID to LOC map.
>
>
>> So if you were product manager for a highly reliable
>> distributed application, I'm sure you would insist that it was
>> coded to detect permanent transport failures and try alternative
>> addresses.
>
> Like a web browser, let's say? Think HTTP handles this? Think again.
> Once the browser successfully connects to a particular IP address for
> a given server name, it nails itself to that address in order to avoid
> an otherwise unsolvable javascript+DNS hacking vector.
Indeed. I'm no lover of the Web Services monster, but again - that's
why they use a namespace abstracted above DNS and run their own security
at layer 7.
Brian
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
