Re: [Ecrit] LoST recursion and Forest Guides

[Karl Heinz Wolf <[e-mail]>]

On Thu, Jul 25, 2013 at 3:55 PM, Rosen, Brian <[e-mail]>wrote:

>  No, it's just a LoST server that knows about trees its in.  Nothing more,
> nothing less.
>
>  It might be run by the access network or, in the case of
> urn:service:sos, the local emergency authorities.
>
>  It's just in a tree (or perhaps more than one tree if it serves multiple
> "top level" services).  It doesn't know about forest guides unless it is at
> the top of the tree (which might be common for some places with
> urn:service:sos where the "tree" is one level, one server).
>
>  If it doesn't know a mapping, if refers/recurs up the tree.  If it's at
> the top of the tree (a root server), it uses mappings it obtains from a FG
> to refer/recur to another tree.
>

Brian, seems that the architecture you are talking about is somehow
differnet from RFC 5582, so could you please point me to the document
describing your architecture so that I can follow up better? Thank you.


> Unless it's at the top of the tree, it's only sending its service boundary
> and URI to its parent.  That's not LoST sync really because it's only one
> way.  It refers anything it isn't authoritative for to its parent, but
> doesn't have any coverage info from the parent.  It doesn't need any.
>

LoST sync can also be used to push coverage reagions up a tree.

karl


>
>  Brian
>
>   On Jul 25, 2013, at 6:47 AM, Karl Heinz Wolf <[e-mail]> wrote:
>
>   On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian <[e-mail]>wrote:
>
>> If there is a service for urn:service:foo, the local LoST server knows
>> how to serve it, or knows how to refer to some entity that can get it.
>>
>
>  Sounds to me that the local LoST server would then actually be a mapping
> server + forest guide. Who should actually operate the local LoST server?
> Would the operator of the local urn:service:sos mapping server of a county
> really want to peer with all other service operators like urn:service:foo
> to exchange mappings via LoST sync so that the local LoST server is able to
> know how to serve them, as you mentioned? Anyway, this seems like lots of
> peering agreements.
>
> Best,
>  Karl
>
>
>>  You can't iterate up the urn:service:sos tree looking for
>> urn:service:foo.
>>
>
>>  The alternatives to searching bottom up is that the FG has to be
>> expensive, like the DNS root - very widely replicated and dispersed.  I
>> don't think that is deployable.  If the FG is only used when you need to
>> cross trees (a query out of area), it's much less costly, much
>>
>   more deployable.  This also applies to intermediate LoST servers.  If
>> the path is top down, all the intermediate servers need to be public.
>>
>>  I want the FG to be able to refuse queries that are from entities it
>> does not know (it knows the leaves in the tree below it and the FGs it
>> peers with).  That is much, much more deployable.
>>
>>  The FG can't be a public resource in my opinion.  We don't have
>> organizations who would be willing to deploy those kinds of services for
>> free like we did for DNS.
>>
>>  A public resource as attractive as an FG (or intermediate servers) that
>> served urn:service:sos would need to withstand the largest DDoS attacks
>> possible.  That is currently 300+ G and heading towards a terabit of attack
>> traffic.  If it's not public, it doesn't need that level of threat
>> mitigation.
>>
>>  The lowest level (the authoritative server) must be publicly
>> accessible.  No way to avoid that I think.  I'm trying to figure out a way
>> to get the FG deployed without that level of expense.  The lowest level is
>> somewhat less attractive of a target than an FG would be, but it still
>> would need to have very significant DDoS mitigation.
>>
>>  Brian
>>
>>
>>  On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf <[e-mail]> wrote:
>>
>>   On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <[e-mail]>wrote:
>>
>>>
>>> If the local server didn't have the answer it could recur or iterate up
>>> the tree.  The client would never have to discover a resolver, the local
>>> server becomes one.
>>>
>>
>>  Brian,
>>
>>  so you suggest that all queries go to a local LoST server, consequently
>> the urn:service:sos tree would be bothered for each query, also for
>> urn:service:foo, which iterates up the urn:service:sos tree, until reaching
>> the forest guide that is able to tell the tree for service foo?
>>
>>  When you say that the local lost server becomes a resolver, I wonder
>> what ist the advantage of discovering a local LoST server? A resolver will
>> verly likely have the responses of all the "local" services in its cache
>> (urn:service:sos as well as any other), and all the other queries can be
>> directed to the right tree via forest guides, without bothering the
>> urn:service:sos tree at all.
>>
>>  Best,
>> Karl
>>
>>
>>>  On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <[e-mail]> wrote:
>>>
>>>   On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <[e-mail]
>>> > wrote:
>>>
>>>>  I want to have LoST discovery find a local LoST server, which nearly
>>>> always has the answer you want.  No FG, no real resolvers.
>>>>
>>>
>>>  Brian, thanks for your answer. So this local LoST server would then be
>>> a LoST mapping server for a specific reagion and a particular service (e.g.
>>> urn:service:sos), do I understand this correctly? Then the client would
>>> have to discover a real LoST resolver as well which it has to consult for
>>> other services.
>>>
>>>   If the local LoST server doesn't have the answer, then we get to the
>>>> forest.  If your local LoST server doesn't have the answer, it's next most
>>>> likely that you need some adjacent server.  So walk up the tree a level and
>>>> find it.
>>>>
>>>>  If something is broken, like the seeker for some reason isn't
>>>> actually local, then you might need to go all the way up to the root of the
>>>> tree, and across (using the FG), and down another tree.  This should be
>>>> really rare, but it can happen.
>>>>
>>>>  Each server in the tree knows the leaves below (coverage and URI) so
>>>> it can recurse or iterate down, and it knows the URI of the next level up
>>>> so it can recurse or iterate up the tree.  That has to work, or the FG
>>>> would have a zillion one level trees.  It doesn't, so the trees have
>>>> intermediate servers that know about the leaves at their level, and can
>>>> recure/iterate up.
>>>>
>>>>  I don't want to see devices start at the FG always.  That would mean
>>>> that the FG is in the path of every emergency call (ignoring caching, which
>>>> obviously helps a lot).  That's not a good design.  Stay local, and use the
>>>> forest only when you have to go out of area for some reason.
>>>>
>>>
>>>  Does this mean the architecture of RFC 5582 is going to be updaded?
>>> After all, this architecture is along the lines of the DNS system, where
>>> queries would also always start at the DNS root servers when ignoring
>>> caching.
>>>
>>>  Best,
>>> Karl
>>>
>>>
>>>
>>>>
>>>>
>>>>   On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <[e-mail]>
>>>> wrote:
>>>>
>>>>     On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <
>>>> [e-mail]> wrote:
>>>>
>>>>>
>>>>>  This means that the national forest guide must be prepared to answer
>>>>> queries from any device at any time.  In particular, it has to be sized for
>>>>> the worst case scenario where a very large number of devices make requests
>>>>> of it, and it cannot refuse a request from any source (as a practical
>>>>> matter).  This makes it a very attractive DDoS target.  In fact, I would
>>>>> argue that a great number of implementations will simply start all queries
>>>>> at the top of the tree in all cases, since the forest guide URI will become
>>>>> well known quickly.
>>>>>
>>>>
>>>> Brian,
>>>>
>>>> I got a bit confused here and I probably missed the discussion on the
>>>> issue. However, the mapping architecture in RFC 5582 describes that a
>>>> seeker queries a resolver, the resolver consults a forest guide and then
>>>> goes to the root of the appropriate tree. So I don’t see how the RFC5582
>>>> architecture should work without the forest guide URI to be known by
>>>> resolvers. Moreover, since the forest guide points to the root of the tree,
>>>> the query has to start at the root. Or are you talking about some private
>>>> LoST deployments inside the NENA network where some other mechanisms and
>>>> architectures apply?
>>>>
>>>> Best,
>>>> Karl
>>>>
>>>>    _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>
>>>>
>>>  _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>>
>>
>>
>  _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>
>