71–80 of 105 posts
The official Android testing framework from Google is also named Espresso. Are we running into a classic hard computer science problem?
Oh no. I bet this reuse of a name has gone unnoticed internally until now.
What does "peering edge" mean? A google search only brings up this article.
Two Google products named Espresso? That won't be confusing at all.
What does "peering edge" mean? A google search only brings up this article.
For a company like google, you would most likely have an edge towards your servers as well as an edge towards your peering partners. The peering edge is therefore the part of the network that is used to connect to BGP peering partners.
Earlier quoted context omitted.
Could you expand a bit more on you comment? I feel I'm missing some context. Specifically, what do you mean by gold plated? Why is it tempting to ignore some aspects of distributed computing? I'm missing a lot of context that you are implicitly implying so could you elaborate?
He's saying that it's so reliable and the throughput is so high that sometimes you have to convince yourself that your computers are halfway across the planet.
Two Google products named Espresso? That won't be confusing at all.
Earlier quoted context omitted.
> This is as foreign a concept from traditional networking and the seven layer OSI model as non von Neumann computing is from von neumann computing Not really. The OSI model doesn't say anything about where I run my routing algorithm and BGP application vs. where my actual switches are. "Classical" networking is an artifact of viewing routers/switches as monolithic blocks that embed all of their functionality in one…
> The OSI model doesn't say anything about where I run my routing algorithm and BGP application vs. where my actual switches are. If you're $BIGASN and you set up an intra building singlemode crossconnect at $BIGCITY to establish settlement free peering (let's say for example a 4 x 10 Gbps bonded 802.3ad circuit) with $OTHERBIGASN, they most assuredly are going to notice if your BGP session and router is not directly…
Why should they care?
> It's bad juju to practice deceptive peering.
I don't understand applying moral judgment to a technical design choice.
Earlier quoted context omitted.
> The OSI model doesn't say anything about where I run my routing algorithm and BGP application vs. where my actual switches are. If you're $BIGASN and you set up an intra building singlemode crossconnect at $BIGCITY to establish settlement free peering (let's say for example a 4 x 10 Gbps bonded 802.3ad circuit) with $OTHERBIGASN, they most assuredly are going to notice if your BGP session and router is not directly…
> Because they are going to be expecting sub-1ms latency to your router, and not "we're taking this session and stuffing it in some sort of tunnel or encapsulation and sending it somewhere else, to where the thing that actually speaks BGP is located". Why should they care? > It's bad juju to practice deceptive peering. I don't understand applying moral judgment to a technical design choice.
Two: it's not moral judgment, it's a technical best practice to actually put routers in the city in which you set up new edge BGP sessions. Pretty basic ISP stuff in fact.
The official Android testing framework from Google is also named Espresso. Are we running into a classic hard computer science problem?
This just shows that Android is treated as the ugly step child even within Google (not that this is not already obvious given the state of the Android API).
Earlier quoted context omitted.
Where do you get the crazy idea that Google doesn't run its links to saturation? It's crazy because it would cost an enormous amount of money. The B4 paper states multiple times that Google runs links at almost 100% saturation, versus the standard 30-40%. That's accomplished through the use of SDN technology and, even before that, through strict application of QoS. https://web.stanford.edu/class/cs244/papers/b4-sigco…
What I mean is that they do not run their links to saturation in the same way as an ordinary ISP. And because their traffic patterns are very different than an ordinary ISP, and much, much more geographically distributed, they can do all sorts of fun software tricks. The end result is the same: Low/no jitter and no packet loss. As contrasted with what would happen if you had a theoretical hosting operation behind 2 x…