[183182] in North American Network Operators' Group
Re: Drops in Core
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Mon Aug 17 11:47:34 2015
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <C6BC6229-2D9E-4A6C-BEFA-D0961160592F@mtin.net>
Date: Mon, 17 Aug 2015 11:47:28 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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.
=E2=80=9CPrivate Peering=E2=80=9D in the strictest sense is still =
peering. You do not have =E2=80=9Cprivate peering=E2=80=9D 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=E2=80=99s 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 =E2=80=9Cwork=E2=
=80=9D, i.e. to transport packets through fibers & routers inside C's =
network? It doesn=E2=80=99t 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=E2=80=99s 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=E2=80=99s 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.
--=20
TTFN,
patrick
> On Aug 17, 2015, at 10:51 AM, Justin Wilson - MTIN <lists@mtin.net> =
wrote:
>=20
> I could see it going through several private peering, but not through =
multiple exchanges. =20
>=20
>=20
> Justin Wilson
> j2sw@mtin.net
>=20
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting =E2=80=93 Data Centers - Bandwidth
>=20
> http://www.midwest-ix.com COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
>=20
>=20
>=20
>=20
>> On Aug 16, 2015, at 8:00 AM, Patrick W. Gilmore <patrick@ianai.net> =
wrote:
>>=20
>> 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:
>>=20
>>>> Is there a paper or a presentation that discusses the drops in the =
core?
>>>>=20
>>>> 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).
>>>=20
>>> It is unlikely packets pass through an IXP more then once.
>>=20
>> =E2=80=9CUnlikely=E2=80=9D? That=E2=80=99s putting it mildly.
>>=20
>> 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 =E2=80=9Cunlikely=E2=80=9D.
>>=20
>>=20
>> [Combining responses]
>> On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen@delong.com> wrote:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> I=E2=80=99m a little confused why most packets are =E2=80=9Clikely to =
traverse multiple peering points=E2=80=9D?
>>=20
>> 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 =E2=80=9Czero or =
one=E2=80=9D AS hop from the destination. I cannot imagine Google or =
Netflix being 50% behind Akamai on that stat. Which clearly implies most =
packets traverse =E2=80=9Czero or one=E2=80=9D AS hop - i.e. one or zero =
peering points.
>>=20
>> 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.
>>=20
>> --=20
>> TTFN,
>> patrick
>>=20
>=20
> Justin Wilson
> j2sw@mtin.net
>=20
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting =E2=80=93 Data Centers - Bandwidth
>=20
> http://www.midwest-ix.com COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
