Subject: [alto] Warren Kumari's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS)

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Dec 2018 12:37:45 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-alto-xdom-disc-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Note: I have not completed my review in detail (and so it may be answered
further down), but I wanted to get this in early...

I'm in no way an ALTO expert (I can barely spell it), so am hoping that I'm
missing something obvious, but I'm really concerned by the scaling implications
/ cost shifting of this.

Let's say this suddenly becomes very popular -- Apple includes this in the iOS
App Store / iMessage app, or Chrome / Firefox decides to start doing this to
find the best datacenter to send traffic to or something...

Until the huge majority of ISPs start answering with these records for all of
their subnets, it seems like there could be a sizable amount of traffic hitting
a: the ISPs recursive servers, b: RIRs, and possibly c: AS112 servers.

E.g: The address I get when I lookup www.google.com is 216.58.193.164.
These are the lookups I'd need to do (I think!) if my $application (or, more
worrying, framework / browser) were to use this:

wkumari$ dig +nocomment +nostats +nocmd NAPTR 164.193.58.216.in-addr.arpa
;164.193.58.216.in-addr.arpa.   IN      NAPTR
193.58.216.in-addr.arpa. 59     IN      SOA     ns1.google.com.
dns-admin.google.com. 226022060 900 900 1800 60

wkumari$ dig +nocomment +nostats +nocmd NAPTR 193.58.216.in-addr.arpa
;193.58.216.in-addr.arpa.       IN      NAPTR
193.58.216.in-addr.arpa. 59     IN      SOA     ns1.google.com.
dns-admin.google.com. 225983176 900 900 1800 60

wkumari$ dig +nocomment +nostats +nocmd NAPTR 58.216.in-addr.arpa
;58.216.in-addr.arpa.           IN      NAPTR
216.in-addr.arpa.       1539    IN      SOA     z.arin.net. dns-ops.arin.net.
2017026288 1800 900 691200 10800

wkumari$ dig +nocomment +nostats +nocmd NAPTR 216.in-addr.arpa
;216.in-addr.arpa.              IN      NAPTR
216.in-addr.arpa.       1665    IN      SOA     z.arin.net. dns-ops.arin.net.
2017026288 1800 900 691200 10800

This is 4 lookups per host / app / connection hitting my recursive servers. In
addition 2 of them hit Google's resolvers, and 2 hit ARINs. Yes, ARIN already
gets many "reverse" queries, and my recursive already does lots of lookups, but
the document doesn't (that I could see) discuss the potential fallout from
potentially *lots* more load. Caching is only slightly effective here -- there
are many many subnets, and e.g the ARIN NoData,NoError response will be cached
for 1800 seconds (30 minutes).

There are other examples -- for example, my laptop is currently on
192.168.0.65. If I try connect to 192.168.1.2 using an app which implements
this, I'll have 4 queries hitting my recursive server (3 of which will get
NXDOMAIN) and 192.in-addr.arpa. hitting ARINs servers.

I'm assuming that I must be missing something obvious here, because I cannot
see how the above sounds reasonable.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 19 Dec 2018 00:23:00 +0100

Warren,

apologies if I restate something obvious, but the key issue for this
discussion is probably that the XDOM procedure is NOT supposed to be run
on your laptop, but instead on a centralized server such as a Content
Delivery Networks's (CDN) HTTP redirect server, a P2P tracker, etc.,
i.e., a "resource directory" in the terminology defined in RFC 5693.

Let me give an example:

1. You (or some software on your laptop) try to access 
http://softwarecompany.example.com/really-big-service-pack.bin
--> DNS lookups for A records, TCP connection, HTTP GET ...

2. The server behind http://softwarecompany.example.com calls
XDOM( $ENV{REMOTE_ADDR}, "ALTO:https" ) , i.e. with your laptop's
IP address, or the "public" IP address of the outermost NAT in front
of your laptop, as a parameter.

3. If the XDOM procedure succeeds, it will return the URI of an
ALTO server (typically the one provided by your ISP).

4. The software on the HTTP server will contact said ALTO server to get
more information about topology, routing costs, etc. from the point of
view of your ISP.  Based on these ALTO informations, it will choose one
of serveral known servers that can provide really-big-service-pack.bin
to your laptop; it chooses the one that gives highest throughput and/or
causes least costs for traffic.  It then returns an appropriate HTTP
redirect to your laptop.

5. Your laptop will get the large file from there.

Of course, all this overhead only makes sense for larger data transfers,
probably not for regular "web surfing". That alone might limit the
number of XDOM invocations.

The DNS queries caused by the XDOM procedure will hit:

- The recursive name server next to the HTTP redirect server, 
  or the tracker, etc. --> reasonable sizing of this name server
  is the duty of the CDN operator, tracker operater etc.

- The authoritative name servers of the ISPs. If XDOM starts to take off
  and is used by many CDNs or trackers, the resulting load on these name
  servers might become an incentive for the ISPs to put the NAPTR RRs in
  place so that the first or second query succeeds.

- If ISPs won't install the NAPTR RRs, XDOM escalates and the queries
  will hit the authoritative servers of the RIRs etc.  But, their
  answers (both NAPTR RRs or NXDOMAIN) can be cached in the recursive
  name servers next to the redirect servers or trackers.  As said, we
  assume the XDOM procedure will not run on billions of PCs, laptops and
  smartphones, but only on some (ten)thousands of CDN servers, P2P
  trackers, etc. in the Internet. Each of the adjacent recursive name
  servers will probably learn quicky all the answers on a /16 or /8
  level, and a cached result can be reused when the XDOM procedure is
  called for a different IP address from the same /8 or /16.  Therefore,
  the load on RIR's servers should be manageable as well.

Does this sound reasonable?

Thanks,

Sebastian

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Dec 2018 19:48:04 -0500

> i.e., a "resource directory" in the terminology defined in RFC 5693.
Ah, you might be restating something obvious, but I'd certainly missed the
above bit / had gotten that part backwards...

> Does this sound reasonable?

I'm still somewhat uncomfortable with some of this (it feels like moving
costs onto $others), and the caching of the "negative" answer isn't very
long (but this could be adjusted).... but, my "somewhat uncomfortable" does
not rise to the level of a discuss, so I will clear it.
(not in front of right machine at the moment)

W

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Dec 2018 16:14:45 +0100

Hi Warren, hi all,

> Am 19.12.2018 um 01:48 schrieb Warren Kumari <[email-masked]>:
> 
> On Tue, Dec 18, 2018 at 6:23 PM Sebastian Kiesel <[email-masked]> wrote:
> Warren,
> 
> Ah, you might be restating something obvious, but I'd certainly missed the above bit / had gotten that part backwards... 

Is there anything that could/should be done to further clarify/make it more obvious in the draft? Like „Warning, don’t do this on your laptop“ ;-) … or more like some operational considerations?

Mirja

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 19 Dec 2018 16:41:39 +0100

Hi Mirja,

The "don't do this on your laptop" is already in section 5.1.1:

[...] Therefore, using the procedures specified
in this document for resource consumer based ALTO server discovery is
generally NOT RECOMMENDED. 

Sebastian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Dec 2018 16:45:08 +0100

Thanks, I guess then we are fine!

> Am 19.12.2018 um 16:41 schrieb Sebastian Kiesel <[email-masked]>:
> 
> Hi Mirja,
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto