Subject: Re: [rrg] Consensus on node reference

From: Toni Stoev <[email-masked]>
Date: Fri, 1 Oct 2010 17:36:18 +0300

2010.9.30 четв 17:58:43 Robin Whittle:
> Hi Toni,
> you asked another question:
> > 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.

> 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.
For traffic arriving on particular interfaces nodes shall make arrangements with their linked gateways. For sending, each node's decision is its own business.

> 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.

> 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.

> 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.

> 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
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.

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.
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.

---

From: Robin Whittle <[email-masked]>
Date: Sat, 02 Oct 2010 16:52:19 +1000

Hi Toni,

Thanks for your reply, in which you wrote:

>> 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.

>> 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.
> 

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

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 14 Oct 2010 00:55:05 +0900

Hi, Toni,

Although I'm not supporting the 'pure'(?) Loc/ID separation (LIS) having a
separate ID and one or more Locators for a node, your arguments defending to
have a 'overloaded' ID to refer to the node itself rather than the interface
are well put, I'd think.

One confusion we still have is that different people mean different things
by LIS. And classifying proposals of different technical flavor all as CEE
is also sometimes confusing. I'm afraid we're not done clear cut with
terminologies yet.

Details of technical operation is more relevant than 'mal-defined'
terminologies, I'd think.

On Fri, Oct 1, 2010 at 11:36 PM, Toni Stoev <[email-masked]> wrote:

> Should the node bother its overseas correspondents with that? Sending them
> packets with interface reply-to addresses.
> For traffic arriving on particular interfaces nodes shall make arrangements
> with their linked gateways. For sending, each node's decision is its own
> business.
>
> 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.
>
> 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.
>
> 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
> 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.
>
> 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.
> 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.
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 14 Oct 2010 01:05:54 +0900

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.

-- 
DY

---

From: Toni Stoev <[email-masked]>
Date: Wed, 13 Oct 2010 23:41:10 +0300

Hi, DY, good to see you writing here.

Location/ID separation is the subject of another thread I have started.
We need a separate discussion on each of these topics in order to get down to the essence of the respective question.

> have a 'overloaded' ID to refer to the node itself rather than the interface

Thank you for this appreciation. I wondered whether I had written understandable English after Robin's remarks.

> is also sometimes confusing. I'm afraid we're not done clear cut with

We can invent new terminlologies, if the current ones do not fit.

> terminologies, I'd think.

Absolutely.