On Tue, Sep 24, 2013 at 12:26 PM, George, Wes <wesley.geo...@twcable.com> wrote: >> From: Randy Bush [mailto:ra...@psg.com] >> i think the two paragraphs you would like to see improved are > [snip] >> i am not against further explanation, send text. but short text. :) > [WEG] just the first paragraph really, and as I'll note below - I'd love to > send text, but I don't understand one of the recommendations >> >> experiments have shown that latency between cache and router, and >> between caches in a cache dag, is not an appreciable issue. > [WEG] ok, so why is "close" important then? > >> i thought bootstrap reachability would be fairly obvious to an operator. >> but if simple routing and no dns dependency were not obvious to you, >> then a few words are indeed needed. or am i missing your point here? > [WEG] yes, completely obvious. Though the last two sentences of your > suggested text in the other email is a useful addition >> >> >> what is missing from the second paragraph? > [WEG] I'm actually happy with second para >> >> >> i am not sure it would be useful to go into the general issue of why >> caches should be proximal to the consumer as it is a rather well- >> explored area, from akamia and limelight to dns. but if you have a >> sentence or two that communicates this, send it over. > [WEG] Generally, I understand why closer is better for content caches > (Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between > the two that I'm not following. Both of the
[CLM] this is about the consumer of the data, right? (and convenience to the operator that hosts the cache). In the akamai/cdn example 'consumer' is 'cable/dsl/etc' user. "Close" is convenient-to-the-operator close to the 'cable/dsl/etc' user. Perhaps 'metro' is close enough for CDNs, balancing latency and backhaul requirements. In the RPKIcache example, 'consumer' is 'routers in your network'. 'Close' is 'close enough that bootstrapping isn't a problem', balanced with 'gosh, maybe I don't want to put one on top of each router! plus associated management headaches to deal with these new systems/appliances'. former benefit from proximity because it reduces latency and reduces unnecessary backhaul and potentially allows for a geographically customized service, resulting in improved user experience. If latency isn't a factor (at least in the average-sized propagation domain), and RPKI caches aren't particularly bandwidth intensive, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending "close" because it confuses the issue and just keep the discussion about secondary dependencies and trust domains. [CLM] I guess one way is to say: "People should understand the dependencies and engineer appropriately" ... which you kind of asked to not say in the original comment. (or is the issue that the dependencies aren't clear?) > > Thanks > Wes George > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. > _______________________________________________ > sidr mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/sidr
