Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt

[Richard Alimi <[e-mail]>]

On Mon, May 14, 2012 at 7:09 AM, Ted Hardie <[e-mail]> wrote:
> On Sat, May 12, 2012 at 12:39 PM, Richard Alimi <[e-mail]> wrote:
> <snipped>
>>> If I understand JASONString correctly, no language tag is supplied,
>>> so human readability will be highly variable,  Fixing that, rather
>>> than relying on a local mapping of the underlying code, is hard
>>> work.  Dropping this optional aspect of the error resource may
>>> be something for the WG to consider; this pushes localization
>>> of the error code description to the endpoint.
>>
>> That seems reasonable.  The intent was to help with debugging (and not
>> display to a user), so I'd either be okay with removing it or keeping
>> it and not worrying about the language.  Is there standard guidance to
>> apply here?
>>
>
> I don't think there is standard guidance.  My personal advice, free
> today and worth what you pay for it, is that localization of error
> codes works better if the client simply has a local table of what maps
> to the code.  If you have to do language negotiation just to get the
> error string right, you're introducing a lot of complexity for
> marginal gain.  If it's a debug string, rather than a user-facing
> error, then marking it such and noting it will contain arcana rather
> than actual error explanations is probably okay.  I don't think many
> people expect a localized stack trace.

Okay - I'll see if anyone else in the WG would like to comment, but
for now we can plan to remove it.

>
> <much snipped>
>> Yes - I see the disconnect.  I'd like to avoid solving the larger
>> deployment considerations under NATs (the deployment consideratoins
>> document should be handling that) in this document and instead focus
>> on the messaging details.
>
> I haven't read the deployment considerations doc, but if this is
> handled there, then a pointer to that would be fine.

Okay, so my memory served me incorrectly here.  I thought it was
handled there, but it wasn't...

>
>> Perhaps it would be best to change the
>> statement w.r.t. STUN to instead say MAY.  This document can certainly
>> give a concise statement of the problems you identified there.
>>
>> How does that sound?
>>
>
> I don't think it is really a question of MAY vs. SHOULD.  The document
> seems to be assigning responsibility to working out the NAT boundary
> problem to the client.  That means the client needs some way of
> determining whether it is going through an address translator to reach
>  the target.  I think keeping it at SHOULD use STUN for cases where a
> translation will take place is correct; the problem is it is SHOULD
> NOT for cases where the source and destination are within a NAT
> boundary.  If you can, I would personally say something brief like
> that, and give a pointer to the deployment considerations document for
> more on how you determine when you have each case.  The optimization
> (omitting the Source Endpoint), just highlights the problem.

Okay, so I think we'll need a bit more discussion on this as to how to
handle it.  I tend to think the deployment considerations document
would be a better place to handle this, but this section of it doesn't
exist yet today (contrary to my memory).

A solution without multiple levels of NATs here would be for the ALTO
Client to do the following algorithm:

  let D = set of destination addresses to which the cost should be queried
  for each address 'a' through which the ALTO Client is reachable
(discovered via STUN, local interface address)
    Pick D_a = { subset of D that can reach the ALTO Client via address 'a')
    query the Endpoint Cost Service with the source address and
destination addresses D_a

Things get hairier with multiple NATs, obviously.  The trickier part
of this would be how a client determines 'a'.  Multiple P2P
applications that I know about already implement logic for detecting
if it can use local address to talk to another peer.  We could
explicitly reference one of those as an example, but AFAIK those
algorithms mostly work only if there's a peer speaking the same P2P
protocol at the other end.

So, how about this which doesn't introduce a dependency on text which
does not yet exist in the deployment considerations document:
(1) as you suggested, indicate that the client SHOULD use STUN to
discover its own IP addresses when query for destination addresses
that are not behind the same NAT boundary, and SHOULD NOT use STUN for
destination addresses that are behind the same NAT boundary.
(2) Add this algorithm sketch as an example for using the Endpoint
Cost Service in a NAT environment, with the statement that determining
D_a may be application-dependent.

Then, if we want to add detail for specific techniques, we could add
those later in the deployment considerations document.

How does that sound?
Rich

>
>
> regards,
>
> Ted Hardie