[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ohta-san's draft
Sean,
1:25 a.m. here. I hit the burn zone I will respond later in the a.m. I
knew we had to go here. But I got to wait. Good mail to dream on for
sure...........:----------------------)
/jim
On Wed, 11 Apr 2001, Sean Doran wrote:
>
> 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>
>