Re: [tae] The internet architecture

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Leslie wrote:
> Keith Moore <moore@network-heretics.com> wrote:
>> Bryan Ford wrote:
>>
>>> I think we absolutely need to migrate both networking APIs and
>>> transport layer protocols themselves toward a model where an
>>> "endpoint" is an opaque (to the transport/application) variable-
>>> length string of some kind, and the transport/application
>>> shouldn't even care much if any what exactly the string is.
> 
>    Pure layering would call for that...
> 
>>> ... for purposes of normal transport and application protocol
>>> operation - i.e., "gimme a TCP-like connection to the endpoint
>>> named 'X'", why should transports and applications need to care?  
> 
>    Let us not forget the other side of that: the application which
> you connect to needs to identify your end somehow...
> 
>> 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.
> 
>> (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.

Sharing fate with lower layers isn't the issue, since the contrary has
been an assumption for many years (dynamic routing, robust
retransmission, E2E security all compensate for lower layer issues).

Sharing fate with the *endpoints* is the issue; designing around that
means you haven't selected your endpoint properly. I.e., if you want
robust file xfer that survives the failure of an individual server, you
want to describe a service to a *system*, not to the individual server.

Multihoming is a mechanism that can help support this, but the point is
to define the service system endpoint properly (i.e., as a service tag,
not a host address). Done correctly, that doesn't necessarily imply
upending what's already been done at the packet endpoint layer.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk4bKMACgkQE5f5cImnZrsdNgCgyMcSxVIHxg1USPG4Tbz7eVrt
lKoAoJXy8Q8+hUzQb8Zt4gMwUz1ntaDa
=fYpp
-----END PGP SIGNATURE-----
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae