Re: Ohta-san's draft

[smd@ebone.net (Sean Doran)]

Jim -

| 8+8 is not needed at all or differential of location and identification to
| achieve multihoming

This is strictly true, since we have multihoming now.
However, what we have now simply sux.

Note that there are very different properties between what
you and greg maxwell talked about while i was asleep, and
what is in Ohta-san's draft.   The latter contains an
important optimization.

Firstly, think of the host's take on "who" vs "where"
separation in terms of masking out the top N bits when
trying to figure out if a received packet is "for me" or
"not for me".  That is, sender may choose a viable path of
which the receiver is currently unaware, and put the path
into the "don't care" top bits.  Routers along the way DO
care, and forward appropriately right to the receiver,
which masks away the for-use-by-routers part (where) and
sanity checks against the for-use-by-hosts (who) part.

Then bear in mind that this split allows for an important
optimization: if the hosts DO care about all the bits, and
given that real Internet traffic is often forwarded on
asymmetric paths, and thus (and for other reasons)
failures may be simplex, then there are NxM combinations
of (source,destination) that must be agreed upon to have a
connection.  Using Ohta's method, since it cares only
about the *sender*'s choices, there are only N or M where
N and M are the number of addresses each host believes
can be used to reach the other.

That is, no "who"/"what" split: NxM.  With "who"/"what" split: Nx1.
Because we don't have to do anything special with choosing
a working/optimal source address.

Given a near future which likely includes both heavily
multihomed popular content sites, and household
multihoming (IP over cable, xDSL, power lines, wireless, ...),
the reduction in power of the function which finds a
working combination of addresses [at startup or after
topology change] is extremely important!

	 Sean. (who is sleep-typing at 0645)

P.S.: Could you please explain "bump-in-the-bump" to me? 
      I've never run across the term before.

P.P.S.: Just to be repetitive in hopes of clarity... 

	O'Dell-san: hosts don't care about what is in top 8 bytes
  	     (well, 6, 7, whatever), that's for routers, 
	     and is filled in by routers -- hosts can
  	     expect zeros and send zeros to indicate
  	     something going into the wide Internet (fsvo "zeros")
	Ohta-san: _receiving_ hosts don't care what's in
  	     the top 8 bytes (well, 6, 7, whatever),
  	     that's for routers, but is filled in by the
  	     sending host -- receiving host can expect
	     random bits and sending hosts fill in
  	     something that makes sense to routers

	Major architectural difference is that O'Dell's proposal 
	*explicitly* requires munging by "middle boxes" 
	to make up for sending-host ignorance, 
	whereas in Ohta's proposal,  hosts are expected to
	be less lazy about knowing what the Internet looks
	like at any given moment, so that they can supply
	top (8,7,6,whatever) bytes which make sense to routers 
	everywhere, and thus not need middleboxes to do rewrites.
	(I suppose Ohta-san is more into the spirit of
	"end-to-end fundamentalism" than O'Dell-san)

	For *both*, major difference to host implementors
	like Bound-san is that you MUST be prepared for a
	packet whose lower (8,9,10,whatever) bytes are
	your identity (EUI-64, or whatnot), and ignore the
	(possibly zero, possibly random) top bytes when it
	comes to replying to the packet.

	Both offer useful features when you leave the top
	N bytes out of checksums and don't use them to
	carry identity around in higher-layer protocols.
	O'Dell's proposal requires this.
- --
Sean Doran <smd@ebone.net>