Re: [amqp] addressing summary

[Ted Ross <tross@redhat.com>]

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.

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

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.

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

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

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

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?

-Ted