[e2e] Port numbers, SRV records or...?

[Noel Chiappa]

    > From: Dave Eckhardt <davide+e2e at cs.cmu.edu>

    > I'm really unsure what an "attachment point" is.

The high-level abstractions in computer science are picked for reasons that
in the end have a very strong streak of practicality (because they make it
easy for us to do things, and organize systems well, etc).

When one looks at "attachment point" this way, they also have a very
practical definition: "the thing/entity, in the entire internet, which the
system of routers deliver packets to".

To be a little more specific, it consists of a tuple: i) the identity of that
small group of routers which can deliver the packets directly to the
destination, without going through another router - the packet has to be sent
to one of these first; ii) the identity of the thing/entity to which that
router then delivers that packet. This is fundamentally a practical
definition: you get the packet to one of those routers, and then they can get
it to the ultimate destination.

To expand on i) a little (I've described it in this way, precisely because of
some of your later comments) the usual situation in actual communication
hardware is that we have things we call "physical subnets", wherein there's
an N^2 connectivity, and where packets can be delivered by lower-level (i.e.
below the internetwork layer) means from any connected station to any other.
So we identify that set of routers by identifying the physical subnet they
are attached to.


    > Saltzer himself points out that this is a troublesome concept for DIX
    > Ethernet ... with MAC addresses serving roughly but not exactly the role.
    > .. an attachment point in a switched Ethernet network: port X on switch
    > aa:bb:cc:dd:ee:ff ..
    > A remote endpoint does not need to resolve a service onto a node and
    > then the node onto such an attachment point for communication to work.

True. But it does need enough info to get it there eventually.

An example is ARP (which exists only because IPv4 addresses were set at 32
bits before anyone conceived of 48-bit hardware addresses :-). ARP allows us
to identify Ethernet interfaces (the ii) from above) with a scope-local
identifier of less than 48 bits, and ARP then turns that into the needed 48
bits - just as the hardware/etc in bridges turns those 48-bit identifiers
into "port X on switch aa:bb:cc:dd:ee:ff".

Think of it as a series of bindings, which the network has to resolve.


    > There's more trouble when one considers wireless networks. I don't
    > think an "attachment point" can be a (latitude, longitude, altitude)
    > tuple, but I don't think it can be anything else either. My "attachment
    > point" could be the base station I'm registered with

Let's try analyzing this case with my i)/ii) model above, and see how that
goes...

    > There are complexities here, though: in a soft-handoff CDMA system, a
    > handset routinely communicates with multiple base stations
    > simultaneously

To me, this suggests that, *from the point of view of the internetwork
system*, that handset has *multiple* "attachment points" - because there are
multiple "places in the entire internet, which the system of routers deliver
packets to".

One has to consider the set of handsets which a base-station X can talk with
a "physical subnet", because the internet architecture's model of a "physical
subnet" requires N^2 connectivity between all stations on that PS. One cannot
consider a group of base-stations, and the handsets they talk to, to be a PS,
because some handsets may not be able to reach some base-stations.

(Yes, yes, I know I'm ignoring the direct handset-handset communication case.
It has been studied, in packet radio networks going back to the 70's. I leave
it as an exercise for the reader.)

This all assumes, of course, that the base stations are internetwork routers,
and so the device has (from the point of view of the set of internet routers)
multiple attachment points.

If not, then you have a "local network" which is made up in turn of packet
switches which have to emulate, through their internal mechanisms, an N^2
network - just like the Internet treated the old ARPANET. That model works
too (and I will resist the temptation to get into a long digression of
whether that's a good design or not :-).

    > Here a remote peer is firmly not involved in knowing my attachment
    > point--it doesn't figure out where I'm attached and then consider paths
    > to me.

The internetwork routers do have to know (at some level of knowledge) which
base stations can be used to get to you (or, if they are not internetwork
routers, which "radio network" they have to deliver the packets to in order
to get them to you).


    > Things get odder in ad-hoc networks or sensor networks, where power
    > control and variable coding mean that each node is connected to every
    > other node at some cost (really a space of (power,delay) values), which
    > may be varying and may be hard to measure.

This is a path-selection problem. The question then becomes "do we want to
tackle that problem within the internet-level path-selection, or do we want
to do it at a lower level, and present an N^2 abstraction to the internetwork
layer".


    > If "attachment point" is challenged by shared-medium Ethernet, switched
    > Ethernet, "wireless Ethernet", CDMA cellular phone systems, ad-hoc
    > networks, and sensor networks, I'm having trouble seeing the crispness
    > of the concept

As I said, "attachment point" is a concept that's useful to the internetwork
layer.

To me, the interesting question really is: "is the N^2 connectivity
assumption that the internetwork-level path-selection currently assumes for a
physical subnetwork really the way to go" (because it means that physical
transmission systems which don't provide N^2 connectivity have to have a
layer in there which provides that), or should we try and expand the
architectural model to support that kind of thing directly?


Note that we do make other physical transmission systems step up to the plate
and have local mechanisms to supply a required service model when their
native service model isn't rich enough - an example is reliabilty. TCP just
doesn't work well with very high BER, so high BER networks have to use FEC or
something, to bring the service model provided *at the interface to the next
layer up* (i.e. the internetworking layer) to that required by the TCP/IP
internetwork.

Is that the right call? Is the N^2 requirement the right call? Interesting
questions...

	Noel