Hi, Robin, As to your point on too much work on nodes to deal with multiple Locators or interfaces:
The workload would not disappear even if you shift the work to application layer as you suggest in dealing with multiple interfaces (IP addresses) in the usual (current) operations. I mean.. the work for a host to deal with multiple IP addresses (for different interfaces) (to smartly deal with multi-homing, traffic engineering, etc.) won't be any less than a host with a node ID to deal with multiple local or remote (the other parties) Locators. On Sat, Oct 2, 2010 at 3:52 PM, Robin Whittle <[email protected]> wrote: > Hi Toni, > > Thanks for your reply, in which you wrote: > > >>> do you consent that nodes (instead of interfaces) have to be > >>> referenced with locators(addresses)/identifiers? > >> > >> I do not support the change you are suggesting, which I > >> understand involves changing the Internet protocols to coerce all > >> nodes to communicate only in terms of themselves, irrespective of > >> what interfaces they are using. > > > > The change is relevant to the general communication between nodes > > where packet relaying occurs. The distinction of nodes' interfaces > > is only adequate in physical communication between neighbors. > > I don't understand these two sentences. > > > >> One reason is that a node might not want incoming traffic to > >> arrive on all its interfaces. Another is that it might not want > >> to send traffic on all its interfaces. > > > > Should the node bother its overseas correspondents with that? > > Sending them packets with interface reply-to addresses. > > That is what happens now, and it involves no complication or extra > effort to the correspondent node. I will call the initiating node > "AAA" and the node it sends packets to, and expects a reply from > "BBB". BTW, I consider "node" and "host" to mean the same thing, but > am using the former since this seems to be your preference. > > It would be more complexity and effort for BBB to meet the > requirements of being told by AAA to send packets back to AAA > addressed to two or more IP addresses - or to two or more > Locators, if Locator / Identifier Separation was introduced. This > would be more effort, since BBB would need to store more information, > make decisions about how to address the packets, and presumably do > extra work to decide which of the two or more IP addresses / Locators > to use, based on whether they were reachable, or some other criteria > such as AAA's preferences for which to use, or perhaps some load > sharing preferences expressed by AAA. > > > > For traffic arriving on particular interfaces nodes shall make > > arrangements with their linked gateways. For sending, each node's > > decision is its own business. > > I agree with the second sentence regarding the current arrangements - > each node sends packets on whichever interface it likes. How the > stack and application decides this depends on how the application is > written. > > However, in Locator / Identifier Separation (as used by Core Edge > Elimination architectures), BBB can have two or more Locators which > match the Identifier for AAA. Then BBB (presumably the stack, since > the application is either written to refer to AAA by its Identifier, > or is referring to AAA via one of its multiple IP addresses) is > expected to make decisions about which of these Locators to use in the > destination field of packets it sends to AAA, and those decisions are > expected to support portability, multihoming, inbound TE (from AAA's > perspective) and probably mobility of AAA. > > So Locator / Identifier Separation involves a great deal more effort > and responsibilities for all hosts - including sending and receiving > more packets and/or longer packets, and also typically involving > longer delays due to the need to look up an Identifier to reliably > ascertain its current Locator(s). I argue against this: > > "Overloading" of Loc & ID functions is good for hosts and should be > maintained 2010-06-22 > http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html > > > >> Some interfaces may be slow, expensive or unreliable - or the > >> node may want to avoid using them so they are ready to accept > >> some other stream of packets. > > > > So if you are a node, make the choice for yourself. Don't make > > remote (more than a hop away) nodes take the burden of your inner > > considerations. > > Sure - it is easy for node AAA to do this regarding outgoing packets, > as long as either: > > BBB uses existing protocols, in which a session is bound to > whichever interface and IP address AAA uses to start the session. > or > BBB uses Loc/ID Separation so it will accept packets from multiple > interfaces of AAA as part of the one session. > > However, this extra burden of work would be placed on all nodes if > Locator / Identifier Separation is introduced. With Loc/ID > Separation, AAA says to BBB, or to any other node it communicates > with, something like: > > My locators are 111, 222 and 333. Please send packets to whichever > of these is reachable. If two or more are reachable, then please > send them preferably to 222, since this is the fastest and cheapest > link. > > > >> Some interfaces might, for policy reasons, be unsuitable for > >> particular types of communication. Some interfaces might use > >> networks with too high a latency, or too high a packet loss, or > >> too small an MTU. > > > > These are node's own regulations, so nodes shall apply them with > > internal means. > > OK - but if you are proposing that the Internet's routing and > addressing system be changed so that a node (AAA) can only identify > itself, for the purpose of receiving packets from another node, by its > node Identifier, with the requirement that all of its interfaces can > be used for receiving packets from the correspondent node (BBB), then > you are requiring BBB to know all these interfaces and to make > decisions about which of these interfaces to send packets to, in a way > which reflects the desires and needs of AAA. For instance, AAA might > have: > > 1 - A 3G interface: not as fast as the others, but which may > persist if the WiFi link dies. However, it may disappear > at any moment, since even without movement, the radio > propagation conditions and base-station management system may > cause the the wireless interface to another base-station which > uses another IP-gateway, in which case this interface will > lose its current IP address or Locator, and gain another one > via the new IP-gateway. > > The traffic on this link is typically paid for at a rate > higher than the other two links below. > > 2 - A WiFi link within the office. This will generally persist > even if the link below disappears. This is generally fast > and involves little or no expense. > > 3 - A 100Mbps or 1Gbps wired Ethernet link. This is faster than > the other two, and generally preferred, but if the device > has its cable unplugged so it can be moved somewhere else, > this will disappear and WiFi link would be the preferred > interface to receive packets on. > > You could have a physical device, such as a laptop (or in the future a > 3G / WiFi Dick Tracy watch, which the latest Apple Nano is fast > approaching) have multiple node Identifiers, even though it it is a > single physical node. Each such node Identifier could have a > different set of Interfaces (AKA Locators in a Loc/ID Separation > architecture). This would provide some flexibility, in that the > node's applications could choose to use a particular node Identifier > from this set depending on what sort of communications the application > was engaging in. > > > >> So, to make your idea workable, I think a given physical > >> computer would need to generate multiple Identities, with each > >> such Identity assigned a set of its Interfaces suitable for > >> particular kinds of communication. > > > > No. Particularization of those kinds of communication is the > > computer's own affair. So the computer shall take care of > > identification of the various kinds of communication internally. > > I don't understand this well enough to respond. > > > >> This can already be done by any application which is suitably > >> written, as I just described. > > > > This is a hand-over of the responsibility for communication policy > > to a certain other layer. OK, to easily jump among "layers" we just > > need Role-Based Architecture, where each function is performed by a > > relevant actor – application, protocol heap, driver. > > http://isi.edu/newarch/DOCUMENTS/hotrba.paper.pdf > > I think this paper is from HotNets 1, 2002: > > "From Protocol Stack to Protocol Heap - Role-Based Architecture." > Robert Braden, Ted Faber, and Mark Handley > > I mentioned that an application could do this already, if it was > written appropriately and was communicating with nodes using either > the same application, or applications which used the same arrangement. > > I was not advocating this as a solution to the routing scaling > problem. I support adding a CES architecture to the existing system > so nodes can continue to refer to each other by IP addresses, as both > Identifier and Locator, with the modified routing system doing extra > work to provide portability, multihoming, inbound TE and mobility on a > highly scalable basis. > > > > And still the > > identification of a node's points of attachment to links is its own > > matter, and we don't need it in the inter-node path selection > > system. > > I agree that with Loc/ID Separation, the routing system can remain as > it is, and doesn't need to know anything about nodes as such. > However, the extra work then needs to be done by all nodes - which I > am opposed to, especially considering the burden this places on > hand-held wireless connected mobile devices. Or wrist-worn or > lapel-worn devices such as the new Nano, or its descendent organisms > "Pico" (ear-worn), "Femto" (brain implant) etc. as soon as one of > these sprouts a radio interface! > > > > When a node communicates to its neighbor it just needs the data > > sent to and received by the neighbor. If the node minds the links > > to its neighbor, it shall take care fore that itself; it may > > arrange special link usage with the neighbor. > > OK - as I noted, this can be done today, if the application is written > to do so. > > With Loc/ID Separation, all nodes are upgraded to arbitrarily handle > the potentially multiple Locators of every node they send packets to. > Each node, in its sending capacity, is therefore responsible for > choosing which Locator to send the packets to - which involves a lot > of work. For instance, if BBB gets a packet with the source > Identifier AAA and some Locators 333, 444 and 555, it can't accept > that these are AAA's true Locators. If it cares at all about which > node will get the packet it sends ostensibly to AAA, then BBB needs to > do a lookup of AAA's Identifier to securely and reliably retrieve the > current Locators for AAA. This involves delays and extra packets. > > > When a node > > communicates to a distant node (more than a hop away) it still just > > needs the data sent to and received by the distant node. The > > sending node generally doesn't need to mind the links of the > > corresponding node; it's the business of the correspondent and its > > neighboring gateways. So, the address/locator a node needs to put > > in a packet to another node just has to be of that entire node. > > I don't understand this clearly enough to respond. Are you discussing > the current arrangements, or Loc/ID Separation? ILNP, Name Based > Sockets - and I think, RANGI and GLI-Split - have the Identifier > referring to the node itself, meaning that packets can be received by > that node, or sent by that node, from any of the node's interfaces. > The Locator typically or in these architectures specifies the > particular interface of the node. > > - Robin > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > -- DY
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
