Subject: [dns-dir] DNS-dir review of draft-ietf-alto-server-discovery-02

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 12 Nov 2011 18:58:27 -0500

<DRAFT please send comments>

	Olafur

--background ---
ALTO := Application-Layer Traffic Optimization
This work started in the P2P world but now seems to have a goal of 
intruding on the turf of CDN's.

Issue not on the table in this review, "why bother with this complicated 
protocol when actual data transfer may take less time"
I think the answer is this only applies to large data transfers.

I tried to keep the review on DNS and DNS related/affected topics.

-- review ----

Summary: This draft needs to be updated due to lack of clarity and 
justifications for design choices and/or change in approach.

Item #1: I was not clear if this document's goal was to help application 
find an ALTO server or the best/closest ALTO sever.
After reading this document a few times it seems be implied that it is 
the second.

Item #2: Section 1 final paragraph, this paragraph seems to be in there 
to say "We picked U-NAPTR and do not want to discuss that any further"
The predecessors of the draft used SRV records or said "SRV or NAPTR can 
be used".
Later in the document there is a well hidden gem that says the NAPTR 
record can contain path to the "db" the ALTO sever uses to answer the 
query. I think that is the real reason you want to use NAPTR not ease of 
deployment.

Item #3 (Section 1.2) YES This depends on MIF and its resolution real 
important when there are multiple interfaces and default interface for 
TCP is not the same as DNS queries will take.
If DNS resolution is on a different interface or is done by a remote 
resolver then the ALTO answer is likely to be sub-optimal or wrong.

Item #4 The client must know the IP address that the sever sees the 
traffic with this requires the client to discover NAT's.

Section 2:
The document has 3 different ways for the client to start the search by 
getting a domain name, and a precedence order among these. The 
assumption here seems to be that the client does not move. I.e. if the 
client has static user inputed search name, but that does not work in 
the location of the computer, is the search then restarted at the DHCP 
specified path ?
(this is not clear but I can interpret section 2 both ways)

Section 3:
As far as I can understand ALTO client will look for NAPTR records that 
guide it to the appropriate ALTO server. The appropriate ALTO server 
depends on the IP address of the client that the ALTO server sees (or 
the world sees?).

Issue #4: The document makes the assumptions that all selection of 
severs can be based on /8, /16, /24, /32 address boundaries (and I guess 
/4*x for IPv6).
and the client discovers this by doing a tree walking up the tree from
<reverse_addr>-.<alto domain name> i.e d.c.b.a.<alto domain name>. The 
text says
"If there is no response for the lookup the domain name is shortened by 
one for the succeeding lookup, until the lookup is successful, ..."

a) "no response" in DNS speak implies timeout, but that only happens 
when things are not working. Thus I interpret this text to say,
	"if no ALTO NAPTR records are found"
but there a multiple different possible answers when ALTO Naptr record 
does not exist:
	No Error  name exist but record does not
	Answer    name exits NAPTR is in answer but none is ALTO
	Rcode=3   name does not exist
the client algorithm needs to handle all of these so please expand.
(related to open issue #2 in section 8)

b) The current approach of having a ALTO sever domain name populate a 
DNS name space what looks like a reverse tree is a significant 
administrative DNS overhead and none of the ALTO documents addresses the 
cost or effect of doing that.
Of course this can be done by having a DNS server that generates the 
answer on the fly based on the query, but that DNS server then needs the 
information to create the answer.
DNS has a record APL that can be used to express this [RFC3123].
Question: Why can the ALTO client not ask the first ALTO server "are you 
the right one?"
and get back yes/no/redirect ?

c) How about about ALTO record that contains the ranges the server 
supports?
This would eliminate the search, a draft idea is
<alto-search-name> 	ALTO	server, <path>, <ranges>
	server is domain name
	path is text string 	
	ranges is APL syntax.

d) Tree walking is a big no-no in specifications see:
http://www.ietf.org/proceedings/80/dnstut.html
If you need to do tree walking be aware it will not work well in IPv6.

 From DNS perspective these are the major issues and I will send textual 
nits and minor clarifications directly to the editors.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Nov 2011 00:35:54 -0500

Hi all,

I'm in the ALTO meeting, and I guess this review hasn't made it to
David Harrington, who's the responsible AD for ALTO.  I'm not sure of
the protocol here -- should this just go to the ALTO list, should it
get forwarded to Dave, or does this have to flow through the ADs?

A

On Sat, Nov 12, 2011 at 06:58:27PM -0500, Olafur Gudmundsson wrote:
> Issue not on the table in this review, "why bother with this
> complicated protocol when actual data transfer may take less time"
> Item #1: I was not clear if this document's goal was to help
> application find an ALTO server or the best/closest ALTO sever.
> After reading this document a few times it seems be implied that it
> is the second.
> 
> Item #2: Section 1 final paragraph, this paragraph seems to be in
> there to say "We picked U-NAPTR and do not want to discuss that any
> further"
> The predecessors of the draft used SRV records or said "SRV or NAPTR
> can be used".
> record can contain path to the "db" the ALTO sever uses to answer
> the query. I think that is the real reason you want to use NAPTR not
> ease of deployment.
> 
> Item #3 (Section 1.2) YES This depends on MIF and its resolution
> real important when there are multiple interfaces and default
> interface for TCP is not the same as DNS queries will take.
> The document has 3 different ways for the client to start the search
> by getting a domain name, and a precedence order among these. The
> assumption here seems to be that the client does not move. I.e. if
> the client has static user inputed search name, but that does not
> work in the location of the computer, is the search then restarted
> at the DHCP specified path ?
> As far as I can understand ALTO client will look for NAPTR records
> that guide it to the appropriate ALTO server. The appropriate ALTO
> server depends on the IP address of the client that the ALTO server
> sees (or the world sees?).
> 
> 
> severs can be based on /8, /16, /24, /32 address boundaries (and I
> guess /4*x for IPv6).
> <reverse_addr>-.<alto domain name> i.e d.c.b.a.<alto domain name>.
> The text says
> "If there is no response for the lookup the domain name is shortened
> by one for the succeeding lookup, until the lookup is successful,
> ..."
> 
> but there a multiple different possible answers when ALTO Naptr
> record does not exist:
> b) The current approach of having a ALTO sever domain name populate
> a DNS name space what looks like a reverse tree is a significant
> administrative DNS overhead and none of the ALTO documents addresses
> the cost or effect of doing that.
> answer on the fly based on the query, but that DNS server then needs
> the information to create the answer.
> Question: Why can the ALTO client not ask the first ALTO server "are
> you the right one?"
> From DNS perspective these are the major issues and I will send
> textual nits and minor clarifications directly to the editors.
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

-- 
Andrew Sullivan
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 16 Nov 2011 13:41:48 +0800

The delay is my fault.  Olafur got it to me, but I haven't had a chance to review it before sending it on to Dave.  I'll do it now.

Thanks to Olafur for writing the review and I apologize for not following through.

- Ralph

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Nov 2011 01:23:48 -0500

> Thanks to Olafur for writing the review and I apologize for not following through.

FWIW, your review request and a different poke from Ted Hardie caused
me to go to ALTO today.  There does appear to be a serious other
problem in what they're working on that is going to cause later
headaches.

I don't yet fully understand what's going on, having read extremely
quickly four or five drafts (including the protocol one, which is
nearly 70 pages of specification) but basically the DNS acts as a kind
of fallback service that gets used for bootstrapping whenever the
Tracker doesn't have the information you want.  That is, by and large
the system is designed around the Tracker, but the DNS is what you
turn to when the Tracker doesn't know.  (This is I think unrelated to
the service discovery thing, which is a different sort of fallback.)

It appears that some proposals are trying to do Stupid DNS Tricks for
ALTO optimization.  The draft-ietf-alto-deployments-02 text currently
points to an expired draft that, if I read it correctly, talks about
having the recursive server modify the DNS response in order to
optimize the traffic according to how ALTO works.  Apparently the
reference is wrong, and I don't know what the replacement does.  I
just sat through a proxy discussion that would require any of these
cases to alter the URI in the U-NAPTR record, thereby of course also
modifying the DNS response.  Needless to say, all of this is going to
break under DNSSEC, and I get the distinct scent in the air of "who
uses DNSSEC anyway?"  

So we have more work to do, I fear.  The nice news is that this
event seems to be an example of cross-area review happening
because of IETF meetings; I cannot remember the last time I paid any
attention to anything in TSV, & I'd never have found any of this out
without going to this WG session.

A

-- 
Andrew Sullivan
[email-masked]