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

[Sebastian Kiesel <[e-mail]>]

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






On Tue, Dec 18, 2018 at 12:37:45PM -0800, Warren Kumari wrote:
> 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.
> 
> 
> 
>