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

[Warren Kumari <[e-mail]>]

On Tue, Dec 18, 2018 at 6:23 PM Sebastian Kiesel <[e-mail]>
wrote:

> 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.
>
>
Ah, you might be restating something obvious, but I'd certainly missed the
above bit / had gotten that part backwards...


> 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?
>

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



>
>
> 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.
> >
> >
> >
> >
>


-- 
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