Re: Fwd: Minutes / Notes

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>

    > Please find attached Geoff minutes from yesterday. Please send comments
    > to me _off list_ and I will add them.

I have a few technical (not editorial) comments on some points in the minutes,
which are therefore of general interest...


    > Iljitsch van Beijnum: the focus is on TCP and you can't have a TCP
    >  that switches addresses mid-flow because you don't have API support
    > Christian Huitema: The reason here is the protocol specification of TCP,
    >  not the API

This is only important if you want TCP connections to be able to survive
having an incoming link fail (i.e. the address on the local end becomes
unreachable to the rest of the network). This may not be an important goal
(e.g. the typical web site wouldn't care).

    > Iljitsch van Beijnum: Obviously we can modify TCP without the API but
    >  we see modifying the network layer
    > Christian Huitema: The socket API constrains the solution you are
    >  saying that the socket API is the problem.

Well, actually you could modify the protocol without modifying the API: the
"address" handed back and forth across between the application and network
layer(s) would be a "token" using the same syntax as an IP address, which
translates internally in the network layer to the appropriate address(es) for
the far end. The problem, of course, is that the "token" is of only local
scope to the host, and thus can't be handed to third parties to allow them to
contact the other end (think the same problem as NAT). That's easy to fix -
you only hand around the name you start with (e.g. DNS - again, same fix as
to this problem in NAT).

There is one issue with modifying TCP (it's a pretty easy upgrade - you
define a TCP option which allows you to specify additional addresses and/or
switch to a different address), which is that with an unmodified TCP on the
other end, you then don't have this capability. But you may not care (see
preceding point).

	Noel