Re: [tae] The internet architecture

John Leslie wrote:

>> Sigh.  Maybe this is unfair, but it seems to me that people keep
>> wanting to take (relatively) straightforward, bulletproof
>> interfaces and replace them with fragile ones that depend on
>> extra layers of indirection,
> 
>    I don't think Bryan said that...
> 
>> and additional services that (a) can fail,
> 
>    Everything "can fail". That doesn't mean we can't engineer a
> layering which makes failure _less_ likely.

No, it doesn't.  But that kind of engineering goes beyond mere protocol
design, and into things like configuration management where we have less
expertise, and less ability to specify what happens.

>> (b) don't share fate with the endpoints
> 
>    It's not clear that application layer _should_ always share fate
> with lower layers. In particular, the application-layer connection
> of a server invoked by a mobile user _shouldn't_ fail when the user
> wanders out of range of a particular cell tower.

The point about fate sharing is relative to the potential for these
mapping layers to fail.  If a mapping layer used by two endpoints can
fail independently of either of those endpoints, the overall reliability
is less than if the mapping layer shares fate with one of its
endpoints... assuming that the reliability of the individual components
is the same for both cases.

>> and (c) are likely to be very sensitive to configuration errors,
>> all for the sake of some notion of architectural purity.
> 
>    Architectural "purity" is often helpful to analyze a situation
> to decide which wish-list items are "easy".

Really?  I more often find it being used to pretend that things are easy
when they are not.

I do think that notions of "purity" or "simplicity" or "elegance" can be
valuable.  If a design choice doesn't seem "pure" according to the
architectural model, it warrants further examination to see if it really
is a good idea.  But notions like "purity" are best regarded as
rules-of-thumb, which can be trumped by actual analysis or experience.

>> I won't claim that you can't do it, or that it's a fundamentally
>> bad idea on its face. I *will* claim that it's a fundamentally
>> bad idea if you don't do very careful engineering on it to make
>> sure that the resulting system is as reliable as it would be
>> without the extra layer of indirection
> 
>    It may be premature to ask for any particular way of increasing
> application-layer reliability. (Several come to mind, though.)

I was just talking about the mapping layer here.

>> - and that includes accounting for the ability of people to
>> misconfigure things.
> 
>    We all know it's a waste of time to aim for 100% foolproof --
> the fools are too ingenious. ;^)

Of course.  But if we design a system to replace the current one that
requires a higher level of clue to configure than the current one, we
should look around and see if the clue level is sufficient.

Or to put it more concrete terms: if DNS is the state-of-the-art for
mapping layers that are deployed on a large scale, and ordinary network
operators can't provision it and configure it so that it's reliable -
maybe we shouldn't be trying to put more trust into mapping layers just
yet.

--

Before we go too far down this path, I should say that at some level I
do sympathize with Bryan Ford's desire to "migrate both networking APIs
and transport layer protocols themselves toward a model where an
'endpoint' is [...] opaque (to the transport/application) [...] and the
transport/application shouldn't even care much if any what exactly the
string is."

The big caveat is that if you really want to make endpoint IDs opaque to
applications, and hide all of the details about locations and network
topology and so forth from applications, you have to do several things:

1. As already mentioned, you have to make whatever service maps between
endpoint IDs and addresses extremely reliable so that you don't degrade
overall system reliability.

2. The lower layers have to "do the right thing" independent of
those endpoint IDs and where they're actually located.  If the details
of locations etc. are hidden from applications, then applications can't
ever be expected to make up for the things like the network's inability
to do things like handle site multihoming.

3. If you are really serious about hiding all of these details from
applications, you need to explain how you're going to build network
management and diagnostic tools.  You also need a lot better system for
detecting and reporting errors caused by network failures so that both
the users and whoever can fix the problem can know what is going on.

But as an application writer, what Bryan is suggesting is pretty much
what I want.  I want to be able to open up a connection to an endpoint
ID and have it stay up even if links go up or down, networks have to
renumber, hosts move, and so on.  Once I have an endpoint ID that binds
to a specific instance of a service, I want to be able to hand that
endpoint ID off to peers on other hosts and have it be usable by those
peers without having to worry about those hosts' locations on the
network or what kinds of addressing they use.  As an application writer,
I don't want to have to know about network topology or addressing realms
or NATs or ULAs or v4/v6 issues.  I don't want to be expected to recover
from failures that result from the network's inability to do
multihoming.  etc.  I want to be able to ask the network to do something
and have the network make its best effort to do that - and by "best
effort" I mean that it shouldn't be possible for the application to do
better even if it does know about the network addressing and topology etc.

But the things that arose in my mind when reading Bryan's statement were
pretty much these:

1. Granted it would be nice for an application to be able to work that
way, but would that much enforced opacity really be a good thing?
Especially in light of the current network architecture's apparent
inability to provide anything close to that kind of programming model?
Again as an applications programmer, I like being able to use a simple
model, but I also find it useful to be able to get under the hood if I
need to do that.

2. It seems to me that the real problems with doing this are not with
defining the API or even the transport layers - and the most significant
benefits are not resulting from the API either.   The hard parts are
building the mapping layer so that it's fast and reliable and secure,
and designing secure signaling between the network, hosts, and mapping
layer, so that the binding IDs continue to work in all cases (and there
are lots of cases to analyze).  The benefits don't seem so much in ease
of programming (though that would be nice) but in having _everything_ be
able to be truly mobile and still be reliable.

When there's so much emphasis on the easy part of the problem, it makes
me wonder whether the true nature of the problem is understood.   It
strikes me as a bit like someone in 1960 saying "if only we could mine
moon rocks, we'd have all of the iron we could possibly need" and then
proceeding to design mechanisms for mining moon rocks without first
figuring out how to get there and back.

Keith
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae