Drops in Core

Sun Aug 16 12:23:44 UTC 2015

On Aug 16, 2015, at 8:15 AM, Job Snijders <job at instituut.net> wrote:
> On Sun, Aug 16, 2015 at 08:00:55AM -0400, Patrick W. Gilmore wrote:
>> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
>>> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
>> 
>>>> Is there a paper or a presentation that discusses the drops in the core?
>>>> 
>>>> If i were to break the total path into three legs -- the first, middle
>>>> and the last, then are you saying that the probability of packet loss
>>>> is perhaps 1/3 in each leg (because the packet passes through
>>>> different IXes).
>>> 
>>> It is unlikely packets pass through an IXP more then once.
>> 
>> “Unlikely”? That’s putting it mildly.
>> 
>> Unless someone is selling transit over an IX, I do not see how it can
>> happen. And I would characterize transit over IXes far more
>> pessimistically than “unlikely”.
> 
> There is another scenario (which unfortunatly is not that uncommon)
> where packets could traverse two IXPs, and no transit is sold over any
> of those two IXs.
> 
> Imagine the following:
> 
> Network A purchases transit from network B & network C. Network B &
> Network C peer with each other via an IXP. Network A announces a /16 to
> network B but 2 x /17 to network C. Network D peers with B via an IX
> (and not with C) and receives the /16 from B, but note that internally
> network B has two more specifics covering the /16 received from C and
> the /16 itself. Network B will export the /16 (received from customer)
> but not the /17s (received over peering) to its peers.
> 
> Because of longest prefix matching, network B will route the packets
> received from network D over an IXP, towards network C, again over an
> IXP. 
> 
> This phenomenon is described extensively in the following
> Internet-Draft:
> 
>    https://tools.ietf.org/html/draft-ietf-grow-filtering-threats-07

Good point.

Although I have trouble believing it is very common, in the sense that I do not believe it is a large number of packets or percent of traffic.

To be clear, I fully believe people are doing the more specifics to provider B but not C. Sometimes there is even a good reason for it (although probably not usually). However, most of the Internet will send traffic directly to B, or even A - especially since most packets are sourced from CDNs[*].

-- 
TTFN,
patrick

[*] I’m counting in-house CDNs like Google, Netflix, and Apple as “CDNs” here. Before anyone bitches, trust me, I am probably more aware of the difference between those and a “real” CDN than nearly anyone else. But those distinctions are orthogonal to the discussion at hand.