Re: [amqp] addressing summary

[Rafael Schloming <rafaels@redhat.com>]

----- Original Message -----
> 
> On 08/21/2014 01:21 PM, Rafael Schloming wrote:
> > ----- Original Message -----
> >> Thanks for this summary.  Here's my first round of questions and comments:
> >>
> >> The where-i-am and who-i-am properties:
> >> =======================================
> >>
> 
> >> It looks to me that we might be trying to create a routing mechanism
> >> based on container hierarchy.  I think this specification should not
> >> endorse any routing mechanism.
> > 
> > Can you expand on this? Do you see something as overly restrictive and/or
> > onerous to implement in what is laid out?
> 
> No, and you've confirmed that it's optional anyway.  I don't believe
> that routing-by-container-hierarchy will work very well, particularly at
> scale or where resiliency is important.  My concern is that the text
> might steer implementers in that direction.

I'm not sure I understand 100% what you mean, but FWIW, the path structure in the address syntax is intended to be fully abstract and not tied in any way to a particular container hierarchy, e.g. it might be more commonly used for topic hierarchies.

> 
> > 
> >> Anonymous Relay Behaviour
> >> =========================
> >>
> >> "Links from the anonymous relay to a container-address are not permitted"
> >>
> >>   - Is container-address the same as who-i-am?
> > 
> > No, although now that you mention it I can see the terminology is a little
> > confusing here. The term "container-address" is what the BNF uses to
> > describe what we previously called "legacy addresses". The term
> > container-address is short for "container scoped address". The reason we
> > wanted to move away from the term "legacy address" is that it would
> > classify things like "$management" as a legacy address which sounds like
> > it is something bad. Perhaps relative/non-global/local or some variant
> > thereof would be clearer.
> > 
> >>   - Why is this prohibition here?
> > 
> > When an outgoing link from an anonymous relay is established, the *target*
> > of that link is used to route messages down that link. Given that the
> > target of that link is owned by container that is remote relative to the
> > relay, a non global address wouldn't necessarily have a well defined
> > meaning here.
> 
> Ok, I agree that this is confusing and now that you've explained it, I
> agree with the prohibition.
> 
> > 
> >> Can we state explicitly that links from an AR to another AR are permitted?
> > 
> > That's a good question. There are really two cases here depending on who is
> > establishing the link. An AR on the receiving side of a link doesn't look
> > at or care about the remote terminus, so if the sending AR is initiating
> > to another AR then that should be fine.
> > 
> > The second case would be where the receiving AR initiates the link. We've
> > defined AR's to route messages along outgoing links based on the remote
> > terminus, so in this case we might need to specify what it means (or
> > whether it is explicitly undefined) when the remote terminus is an AR.
> > 
> > In any case I believe the short answer is yes it should be permitted and we
> > probably need some text in there to clarify what it means in the latter
> > case.
> 
> For reference, Qpid Dispatch uses an endpoint capability (in ATTACH) to
> signal that AR-to-AR links are accepted, regardless of role.
> 
> 
> >> Request/Response Examples
> >> =========================
> >>
> >> The term "match" is used throughout the summary.  Does this word have
> >> special meaning or does it simply mean "is equal to?"
> > 
> > It doesn't just mean equal, it also means pattern matching in the case of
> > address spaces. The only patterns permitted are prefixes, so this should
> > be a pretty simple matching operation. This is logically roughly analogous
> > to checking if an ip address matches a given netmask. Hopefully the
> > motivation for this is pretty clear, you want to be able to route based on
> > prefixes not just on exact matches.
> 
> Is it necessary to mandate how addresses are matched by ARs?  Is it
> harmful to allow AR implementers to use different matching and lookup
> algorithms?

I don't think what is suggested restricts what an AR implementer could do. You always have the option of specifying a full wildcard or just using an AR <-> AR link with a custom filter.

As for whether it's necessary, I do think we need to somehow address the inverse-of-the-anonymous-publisher problem. If you recall the anonymous publisher problem is when a given endpoint wants to send messages to many (possibly thousands) of different addresses. Currently the only standard way to do this (without an AR) is to open a separate link to each address. Making this efficient at the protocol level is actually possible, but it adds some undesirable complexity to implementations, so of course we'd like to be able to avoid that. The inverse of this problem is where you want to receive from many (possibly thousands) of different addresses, you need to have a link open for each one. This is in some ways worse because it is more difficult to optimize at the protocol level. Having a standard syntax for specifying multiple addresses and address spaces provides a way for the AR to solve this problem as well.

It's probably not clear from the summary, but what is described about the AR is really more about the AR interacting with other non AR endpoints. My impression is that the routing cases you are considering would be more AR <-> AR scenarios, and in those cases the patterns would perhaps be useful only for more gateway oriented scenarios. In a routed network I would expect there to be a lot of AR <-> AR links and the messages that flow down them would be determined by some out of band mechanism.

> Like I said above, this prefix-only matching might lead an implementer
> in a particular direction with regard to routing.  For one thing, this
> addressing scheme is very topology-oriented.  Topology-oriented
> addresses are necessary to support reply-to (as you describe below).
> But it will be equally necessary to support mobile addresses that might
> have no hierarchy, or organizational/political hierarchy which is not
> related to routing.

I can see how it might appear that way if you think purely about the low level routing aspects, but I do think that kind of pattern matching is pretty standard/useful in a logical context also, e.g. for topic hierarchies. Perhaps some added examples that show some higher level uses might help?

> > 
> >> Example (2) should be removed in my opinion.  This try-until-I-succeed
> >> protocol is not very elegant.  Furthermore, this will not scale well in
> >> a network of relays because the address, created by the endpoint, will
> >> need to be propagated throughout the network before it can be used.
> >> This will create race-conditions in request/response scenarios where the
> >> request arrives at the server before the server's relay is ready to
> >> forward the response.
> > 
> > This wasn't intended to imply some sort of try-until-I-succeed protocol.
> > The "If the link succeeds" language is just being precise about not
> > ignoring the possibility of errors.
> 
> My objections still stand, particularly with respect to the
> request/response pattern.

Can you clarify which objections?

> > 
> >> What is missing here is dynamic-address-assigned-by-the-peer.  This has
> >> been proven in implementation and it scales efficiently without race
> >> conditions.  I should emphasize that a dynamic address is _not_ the same
> >> as a temporary queue.
> >>
> >> We've had the dynamic-address discussion a half dozen times and it keeps
> >> dropping off the radar.  Am I the only one who thinks this is important?
> > 
> > We've actually spent quite a bit of time trying to accommodate the scenario
> > you're talking about, so you're definitely not the only one who thinks it
> > is important. I think this set of definitions actually does provide a
> > solution to the dynamic-address-assigned-by-the-peer problem with a
> > (hopefully) minor caveat. I'll try to step through how I think it would
> > work below.
> > 
> >     Client                                                       Router
> > 
> >     open(who-i-am="/client1234")                       ---->
> >                                                        <----
> >                                                        open(where-i-am="//example.org/router1")
> > 
> >     attach(role=receiver, source=AR,
> >            target="//example.org/router1/client1234")  ---->
> > 
> > Note that in the above scenario no propagation is necessary because the
> > client is requesting messages be routed from the predeclared address space
> > of the router. The minor caveat here is that the router declares its full
> > namespace so the client has to append a unique portion onto the end of it.
> > For clarity I used the who-i-am address, but any unique value would do,
> > e.g.:
> > 
> >     attach(role=receiver, source=AR,o
> >            target="//example.org/router1/<UUID>)       ---->
> > 
> >     attach(role=receiver, source=AR,
> >            target="//example.org/router1/client1234/1) ---->
> > 
> >     attach(role=receiver, source=AR,
> >            target="//example.org/router1/client1234/2) ---->
> 
> Ok, I think this mechanism mostly addresses the "temporary routable
> address" problem.  There's still the issue of clients being responsible
> for ensuring their addresses are unique within the address space.
> 
> Would it be a violation of the intent of the text if a router container
> provided a different where-i-am to each of its peers?  This would allow
> each peer to have its own unique space in which to assign temporary
> addresses.

The text doesn't preclude that, but the peer would have no way of knowing it was guaranteed to be unique given the current definition, so it would still need to add a unique component.

The idea behind not having it be unique is that it is more flexible. While the peer does need some strategy to ensure uniqueness, the peer also has the option to use the same mechanism for stable (non temporary) addresses.

> 
> > 
> > Depending on the capabilities of the router you might also be able to
> > establish a topology-independent link like this:
> > 
> >     attach(role=receiver, source=AR,
> >            target="/client1234")                       ---->
> 
> +1
> 
> > 
> > For background, the who-i-am/where-i-am naming is motivated by an analogy
> > to mailing addresses, e.g. who-i-am might be "Bob Smith", but at any given
> > moment I might be located at Home, Work, a Hotel, etc. The
> > dynamic-address-assigned-by-the-peer scenario is analogous to checking
> > into a hotel. The hotel doesn't tell me who I am, I'm still "Bob Smith",
> > the hotel just tells me where it is located (e.g. Marriot Hotel, 192
> > Broadway, NY NY). It's then my choice whether I want to give out my
> > address as "Bob Smith"@"Marriot Hotel, 192 Broadway..." or whether I want
> > to give out my address as "Bob Smith"@Home or "Bob Smith"@Work.
> > 
> 
> I'm not sure I'm getting this analogy.  If I want to call you, I don't
> want to have to first find out where you are or what hotel you're
> staying in.

I intentionally didn't use phones as an analogy because there are too many layers of magic going on under the covers there. I certainly agree that's a behavior you ultimately want, but as an analogy it doesn't provide much insight into how to achieve that.

I don't know if this helps, but the way I would describe your scenario with postal addressing is that you want to send me a letter without worrying about where I am. Typically this just means you default the "location" portion of my address to Home. I will then eventually get it when I return Home, but if I want to get fancier than that I can have some agent (or perhaps my butler in this pre-phone world) forward it from my Home to wherever I may currently be. If I'm gonna be gone for a while and my butler gets lazy, he can register a temporary change of address with the local post office, which in turn could choose to propagate the change of address information to as much or as little of the rest of the postal network as is appropriate.

IIRC, this is roughly how mobile ip routing works.

> It's not clear to me what I would do with my peer's who-i-am address.
> Is who-i-am intended to be a form of "logging into the network",
> inviting the peer to distribute the address where it needs to go?  If a
> container provides a who-i-am, must it also create an inbound link from
> the AR with the same address as its target?

I'm not sure exactly what you mean by "logging into the network", but basically the who-i-am is really just a declarative statement about the address of the endpoint. As an intermediary depending on your capabilities you may or may not be able to route messages to the endpoint based on that address. There is no implication that an intermediary needs to provision or propagate routing information about the who-i-am, although that would be a possibility for certain implementations. In general address provisioning/propagation of routing information is definitely not in the intended scope of any of the described mechanisms.

To answer your second question, if a peer provides a who-i-am then it does need to create the inbound link if the partner does not advertise the router capability. If the partner does advertise the router capability then the peer can expect the partner to initiate any links necessary to deliver messages to the who-i-am address.

--Rafael