Re: [amqp] addressing summary

[Rafael Schloming <rafaels@redhat.com>]

----- Original Message -----
> Thanks for this summary.  Here's my first round of questions and comments:
> 
> The where-i-am and who-i-am properties:
> =======================================
> 
> Does a container's who-i-am have to be a subset of its where-i-am?

No, they can be pretty much unrelated. I've tried to describe a bit more at the end.

> It says that peers can define a subspace within a container's
> where-i-am.  How is this negotiated in the protocol since the OPEN
> performatives don't handshake.  Does a container that wants to create a
> subspace need to hold its OPEN frame until it receives the peer's OPEN
> frame?

No, the connection open still simply exchanges information. The link establishment phase is what actually claims addresses, e.g.:

  Container A                         Container B

    open(who-i-am="/Container-A") ---->
                                  <---- open(where-i-am="//example.org/foo")

    attach(role=receiver, target="//example.org/foo/A") --->

> What if both containers want to create a subspace?

Same as above, but both would create links in the second step.

> Are where-i-am and who-i-am optional properties?  Even for routers?

I don't see any reason offhand why they would need to be required.

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

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

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

> Can we add something like the following?  "Links established from an AR
> with the dynamic flag set are assigned a unique address by the AR"

I think that would contradict the behavior the core spec defines for dynamic. My hope is that we can support all the necessary scenarios without use of dynamic. (See below for more details.)

> Request/Response Examples
> =========================
> 
> What is meant by "Message properties define the quality of service?"

That's just an observation about example 1. Because the message isn't associated with any given link, an intermediary would need to use the message properties to establish how long to keep a message or whether it needs to be stored durably.

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

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

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

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")                       ---->

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.

--Rafael