Hi, Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side. Is this correct? Glen
I'd guess first\last\peering. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Glen Kent" <glen.kent@gmail.com> To: nanog@nanog.org Sent: Saturday, August 15, 2015 11:47:31 AM Subject: Drops in Core Hi, Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side. Is this correct? Glen
On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent@gmail.com> wrote:
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core.
Hi Glen, I would expect congestion loss at enough peering points (center of the core) to put it in the same league as noisy cable at the edge. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Hi Bill, Just making sure that i get your point: Youre saying that the probability of packet drop at peering points would roughly match that at the edge. Is it? I thought that most core switches have minimal buffering and really do cut-through forwarding. The idea is that the traffic that they receive is already shaped by the upstream routers. Glen On Sat, Aug 15, 2015 at 10:33 PM, William Herrin <bill@herrin.us> wrote:
On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent@gmail.com> wrote:
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core.
Hi Glen,
I would expect congestion loss at enough peering points (center of the core) to put it in the same league as noisy cable at the edge.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Sat, Aug 15, 2015 at 1:07 PM, Glen Kent <glen.kent@gmail.com> wrote:
Youre saying that the probability of packet drop at peering points would roughly match that at the edge. Is it? I thought that most core switches have minimal buffering and really do cut-through forwarding. The idea is that the traffic that they receive is already shaped by the upstream routers.
Hi Glen, It a capacity question. Several core networks [cough Verizon cough] intentionally under-provision the "settlement-free" peering links to other core networks. You can't cut-through when the destination interface already has a queue of packets waiting to be sent. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges. However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges. YMMV. Owen
On Aug 15, 2015, at 10:07 , Glen Kent <glen.kent@gmail.com> wrote:
Hi Bill,
Just making sure that i get your point:
Youre saying that the probability of packet drop at peering points would roughly match that at the edge. Is it? I thought that most core switches have minimal buffering and really do cut-through forwarding. The idea is that the traffic that they receive is already shaped by the upstream routers.
Glen
On Sat, Aug 15, 2015 at 10:33 PM, William Herrin <bill@herrin.us> wrote:
On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent@gmail.com> wrote:
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core.
Hi Glen,
I would expect congestion loss at enough peering points (center of the core) to put it in the same league as noisy cable at the edge.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Sat, Aug 15, 2015 at 1:21 PM, Owen DeLong <owen@delong.com> wrote:
I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges.
However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges.
Hi Owen, Generally speaking there are zero or one settlement free peering points in the active path between any two edges. Not always, but close enough to it to discount the exceptions. Speaking for my own experience, I almost never see loss on my Verizon FiOS edge but see loss at the various Verizon borders with other networks -all the time-. They keep pitching me on upgrading to 75/75 but that isn't the upgrade I need. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
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). That sounds too aggressive for the middle mile. Dont you think so? On Sat, Aug 15, 2015 at 10:51 PM, Owen DeLong <owen@delong.com> wrote:
I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges.
However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges.
YMMV.
Owen
On Aug 15, 2015, at 10:07 , Glen Kent <glen.kent@gmail.com> wrote:
Hi Bill,
Just making sure that i get your point:
Youre saying that the probability of packet drop at peering points would roughly match that at the edge. Is it? I thought that most core switches have minimal buffering and really do cut-through forwarding. The idea is that the traffic that they receive is already shaped by the upstream routers.
Glen
On Sat, Aug 15, 2015 at 10:33 PM, William Herrin <bill@herrin.us> wrote:
On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent@gmail.com> wrote:
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core.
Hi Glen,
I would expect congestion loss at enough peering points (center of the core) to put it in the same league as noisy cable at the edge.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
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. Kind regards, Job
On Aug 15, 2015, at 1:41 PM, Job Snijders <job@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”. [Combining responses] On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen@delong.com> wrote:
I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges.
However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges.
I’m a little confused why most packets are “likely to traverse multiple peering points”? Most packets these days are sourced from one of three companies. (Which Owen should know well. :) At least one of those companies published stats saying the vast majority of packets are “zero or one” AS hop from the destination. I cannot imagine Google or Netflix being 50% behind Akamai on that stat. Which clearly implies most packets traverse “zero or one” AS hop - i.e. one or zero peering points. Finally, I would love to see data backing up the statement that packets are more likely to drop at one edge (assuming the destination?) than at a peering point. -- TTFN, patrick
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@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 Kind regards, Job
On Aug 16, 2015, at 8:15 AM, Job Snijders <job@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@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.
On Sun, Aug 16, 2015 at 8:00 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Aug 15, 2015, at 1:41 PM, Job Snijders <job@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”.
Hi Patrick, I'm told it happens relatively often in networks supporting a lot of schools. Being an unpaid pass-through for schools paying other ISPs functions as a loss-leader that attracts more schools as customers. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Aug 16, 2015, at 8:44 AM, William Herrin <bill@herrin.us> wrote:
On Sun, Aug 16, 2015 at 8:00 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Aug 15, 2015, at 1:41 PM, Job Snijders <job@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”.
Hi Patrick,
I'm told it happens relatively often in networks supporting a lot of schools. Being an unpaid pass-through for schools paying other ISPs functions as a loss-leader that attracts more schools as customers.
Lots of people have mentioned “but XXX happens” to me. And you are all correct. XXX happens. My point was not “this never happens”. Just those other topologies are a tiny, tiny fraction of the packets flowing on the Internet. Most packets flow from CDNs to broadband. And those packets flow mostly direct (on-net or PNI), or over a _single_ IXP. Corner cases exist, but they are just that - corner cases. -- TTFN, patrick
I could see it going through several private peering, but not through multiple exchanges. Justin Wilson j2sw@mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting – Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric
On Aug 16, 2015, at 8:00 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Aug 15, 2015, at 1:41 PM, Job Snijders <job@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”.
[Combining responses] On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen@delong.com> wrote:
I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges.
However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges.
I’m a little confused why most packets are “likely to traverse multiple peering points”?
Most packets these days are sourced from one of three companies. (Which Owen should know well. :) At least one of those companies published stats saying the vast majority of packets are “zero or one” AS hop from the destination. I cannot imagine Google or Netflix being 50% behind Akamai on that stat. Which clearly implies most packets traverse “zero or one” AS hop - i.e. one or zero peering points.
Finally, I would love to see data backing up the statement that packets are more likely to drop at one edge (assuming the destination?) than at a peering point.
-- TTFN, patrick
Justin Wilson j2sw@mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting – Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric
Terms get over-used & overloaded in many cases. So it is difficult to tell if this is just a miscommunication, but I think I disagree with this statement. “Private Peering” in the strictest sense is still peering. You do not have “private peering” with your transit provider, even though the traffic goes over a dedicated link. As such, I do not see how a packet would go over multiple private peering - public or private - links except in a few corner cases such as the ones stated earlier in the thread. Let’s consider a more general case. Assume a packet traverses several ASes: A -- B -- C -- D -- E There should be no more than one peering relationship in that whole chain, if any. (Zero is a valid number as well.) If, for instance, B peers with C and C peers with D, then who is paying C to do “work”, i.e. to transport packets through fibers & routers inside C's network? It doesn’t even work if B peers with C and D peers with E. Why would C pay D or vice versa when they are not paid on the other side? The reason peering works is because each peer is paid, either by their own user or a downstream. When traffic goes over a network without being paid at either source or destination, something is wrong. Or worse, when a network pays to send traffic without being paid to receive it, or the reverse, things are very broken. Even the corner cases still have people paying in some sense. In Bill’s example, networks giving free transit to schools, there is value traded. The ISP providing the service is either expecting more revenue from the school or revenue from others because they transit the school. In the case of a transit provider providing free transit to eyeballs in order to balance ratios, the value is the inbound demand. In Job’s example, you are paying both providers. Even though one has a de-aggregate link, the other is still getting paid. Etc., etc. If each case, if the expected value does not materialize, the ISP will stop providing the service. In summary: While there are exceptions to many (all?) rules, we are discussing generalities. And in general, companies who perform work without being paid tend not to last very long. -- TTFN, patrick
On Aug 17, 2015, at 10:51 AM, Justin Wilson - MTIN <lists@mtin.net> wrote:
I could see it going through several private peering, but not through multiple exchanges.
Justin Wilson j2sw@mtin.net
--- http://www.mtin.net Owner/CEO xISP Solutions- Consulting – Data Centers - Bandwidth
http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric
On Aug 16, 2015, at 8:00 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Aug 15, 2015, at 1:41 PM, Job Snijders <job@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”.
[Combining responses] On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen@delong.com> wrote:
I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges.
However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges.
I’m a little confused why most packets are “likely to traverse multiple peering points”?
Most packets these days are sourced from one of three companies. (Which Owen should know well. :) At least one of those companies published stats saying the vast majority of packets are “zero or one” AS hop from the destination. I cannot imagine Google or Netflix being 50% behind Akamai on that stat. Which clearly implies most packets traverse “zero or one” AS hop - i.e. one or zero peering points.
Finally, I would love to see data backing up the statement that packets are more likely to drop at one edge (assuming the destination?) than at a peering point.
-- TTFN, patrick
Justin Wilson j2sw@mtin.net
--- http://www.mtin.net Owner/CEO xISP Solutions- Consulting – Data Centers - Bandwidth
http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric
On Sat, Aug 15, 2015 at 1:31 PM, Glen Kent <glen.kent@gmail.com> wrote:
Is there a paper or a presentation that discusses the drops in the core?
Hi Glen, Probably, but I don't know where to point you.
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). That sounds too aggressive for the middle mile. Dont you think so?
Break it in to five legs: 1. Your immediate last mile 2. The set of networks you directly or indirectly pay to transmit and receive packets 3. The border link between your networks and the remote user's networks 4. The set of networks the remote user directly or indirectly pays to transmit and receive packets 5. The remote user's immediate last mile In some cases, your packets meet on a network which both you and the remote user pay for. In those cases, leg 3 does not exist. However, those cases are less common than the one where neither of you pays the same networks. Legs 1 and 5 are often over noisy copper wire suspended from a street pole. Leg 3 is routinely under-provisioned (too little bandwidth for the traffic demand). Legs 2 and 4 rarely exhibit loss for long. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Hi Glen, If you first list the causes of a dropped packet, then you can figure out how likely they are at different points in time (first\last\peer\etc) by making some assumptions. Here's an **example**: *Cause | Location | Likelihood* Congestion | Last mile | Low Congestion | First mile | Low Congestion | Peering | Medium Layer 1 | First mile | Low Layer 1 | Core | Low Layer 1 | Last mile | High You can even go as far as drawing a cause and effect diagram for each location. Then you can collect real world data and fine tune your assumptions. Rafael On Sat, Aug 15, 2015 at 11:47 AM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side.
Is this correct?
Glen
Quite the inverse, I'd say; most of the capacity headaches center around the handoff between networks, and most of the congestion points I come across are with private peering links where one party or the other is unwilling or unable to augment capacity. The first and last mile are fine, but the handoff between the networks is where congestion and drops occur. As others have noted, this will vary greatly depending on the network in question--so asking a broad community like this is going to yield a broad range of answers. You aren't going to find one single answer, you'll find a probability curve that represents the answers from many people running different networks. You'll find the location of packet drops tends to shift depending on where companies are willing to spend money; some companies will spend money on the access layer to ensure no drops happen there, but are less willing to pay for capacity upgrades at peering handoffs. Other networks will short-change their access, but maintain a well-connected peering edge. So--short answer is there is no one answer to your question. Collect the different answers, plot the curve, and decide where along the curve you want *your* network to land, and build accordingly. Nobody has infinite money, so nobody builds to a level to ensure zero loss probability to every destination around the planet. Matt On Sat, Aug 15, 2015 at 9:47 AM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side.
Is this correct?
Glen
On Sat, 15 Aug 2015, Glen Kent wrote:
bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side.
Is this correct?
1. TCP (and most other IP protocols) depends on, and forces packet congestion and drops. Packet drops alone are not necessarily a measure of network quality. Other than some laboratory conditions, there must always be some congestion somewhere. 2. Packet queuing and drops are most likely at network transition points. Usually speed or latency transition points, but also network administration transition points. 3. Packet queuing and drops are less likely between network transition points, i.e. across the same network (LAN, WAN, ISP, etc). That's why some ISPs claim they have 0% packet loss on their network. They don't include network transition points in their statistics; but have worse end-to-end performance than another network which includes 0.1% packet drops in their reported statistics. Generally I don't believe ISPs that claim 100% uptime or 0% packet loss.
On 8/15/15 09:47, Glen Kent wrote:
Hi,
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side.
What do these terms mean in a world where my EC2 VM talks to my GCE VM? It doesn't seem unreasonable that the DC bandwidth on either end dwarfs the "core" capacity between the two.
Is this correct?
Glen
On Mon, Aug 17, 2015 at 1:44 PM, Scott Whyte <swhyte@gmail.com> wrote:
On 8/15/15 09:47, Glen Kent wrote:
Hi,
Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side.
What do these terms mean in a world where my EC2 VM talks to my GCE VM? It doesn't seem unreasonable that the DC bandwidth on either end dwarfs the "core" capacity between the two.
there's some other work going on: <http://www.bitag.org/documents/BITAG_Press_Release_-_Announcing_Prioritization_and_Differential_Treatment_Topic.pdf> which pokes a bit at this idea of packet drops (from the 'what if I prioritize traffic? or differentiate between traffic types?' perspective). I imagine that a topic of conversation is that: "hey, do we get meaningful drop numbers, or does prioritization/differentiation matter, in the core of a network or only at the network edges?" mostly bitag is focused on 'consumer' edges, so they may not look at 'inside a a datacenter' problems.
participants (12)
-
Christopher Morrow -
Glen Kent -
Job Snijders -
Justin Wilson - MTIN -
Matthew Petach -
Mike Hammett -
Owen DeLong -
Patrick W. Gilmore -
Rafael Possamai -
Scott Whyte -
Sean Donelan -
William Herrin