Re: Data on latency and loss-rates during congestion DDoS attacks

[Saku Ytti]

On Sat, 25 Jan 2020 at 05:30, Amir Herzberg  wrote:

> That's actually roughly the range of losses we focused on; but it was based 
> on my rough feeling for reasonable loss rates (as well as on experiments 
> where we caused losses in emulated environments), and a reviewer - 
> justifiably - asked if we can base our values on realistic values. So I would 
> love to have real value, I'm sure some people have these measured (I'm 
> actually quite sure I've seed such values, but the challenge is recalling 
> where and finding it...).

DDoS is very very cheap, if there is a single global egress for given
interface then the DDoS traffic can easily be 100 times the egress
capacity (1GE egress, 100GE DDoS). I'm very skeptical if FEC will
help, I think this is case of cat and mouse, based on data you see now
it may seem reasonable, but now is only result of minimum viable ddos,
which is trivial to increase should need occur. Similarly DDoS attacks
are excessive dumb often, like dumb UDP ports which are easy drop, but
should we solve protection well for these, it's trivial to make it
proper HTTPS TCP SYN.

> Also, latency values (under congestion) would be appreciated. Also here, we 
> used a range of values, I think the highest was 1sec, since we believe that 
> under congestion delays goes up considerably since many queues fill up [and 
> again I seem to recall values around this range]. But here the reviewer even 
> challenged us and said he/she doubts that delays increase significantly under 
> network congestion since he/she thinks that the additional queuing is 
> something mostly in small routers such as home routers (and maybe like the 
> routers used in our emulation testbed). So I'll love to have some real data 
> to know for sure.

Backbone device interface can add hundreds of milliseconds during
congestion, but more commonly we're talking about tens of milliseconds
during congestion and low microseconds to high nanoseconds outside
congestion.
Backbone device buffer space is highly googlable, BRCM
trident/tomahawk styte boxes have very little, but they are more
intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar,
EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper
Paradise, Broadcom Jericho all will buffer high tens of milliseconds
to low hundreds.

-- 
  ++ytti

Re: Data on latency and loss-rates during congestion DDoS attacks

[Amir Herzberg]

Damian, thanks!

That's actually roughly the range of losses we focused on; but it was based
on my rough feeling for reasonable loss rates (as well as on experiments
where we caused losses in emulated environments), and a reviewer -
justifiably - asked if we can base our values on realistic values. So I
would love to have real value, I'm sure some people have these measured
(I'm actually quite sure I've seed such values, but the challenge is
recalling where and finding it...).

Also, latency values (under congestion) would be appreciated. Also here, we
used a range of values, I think the highest was 1sec, since we believe that
under congestion delays goes up considerably since many queues fill up [and
again I seem to recall values around this range]. But here the reviewer
even challenged us and said he/she doubts that delays increase
significantly under network congestion since he/she thinks that the
additional queuing is something mostly in small routers such as home
routers (and maybe like the routers used in our emulation testbed). So I'll
love to have some real data to know for sure.

Apart from knowing these things for this specific paper, I should know them
in a well-founded way anyway, as I'm doing rearch on and teaching net-sec
(incl. quite a lot on DoS) :)

-- 
Amir



On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher  wrote:

> I suggest testing with a broad variety of values, as losses as low as 5%
> can be annoying, but losses at 50% or more are not uncommon.
>
> Damian
>
> On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg 
> wrote:
>
>> Dear NANOG,
>>
>> One of my ongoing research works is about a transport protocol that
>> ensures (critical) communication in spite of DDoS congestion attack (which
>> cannot be circumvented), by (careful) use of Forward Error Correction. Yes,
>> obviously, this has to be done and used carefully since the FEC clearly
>> increases traffic rather than the typical congestion-control approach of
>> reducing it, I'm well aware of it; but some applications are critical (and
>> often low-bandwidth) so such tool is important.
>>
>> I am looking for data on loss rate and congestion of DDoS attacks to make
>> sure we use right parameters. Any chance you have such data and can share?
>>
>> Many thanks!
>> --
>> Amir Herzberg
>> Comcast chair of security innovation, University of Connecticut
>> Foundations of cybersecurity
>> ,
>>  part
>> I (see also part II and presentations):
>> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises
>> 
>>
>>
>>

Re: akamai yesterday - what in the world was that

[bzs]

On January 24, 2020 at 16:59 list-nan...@dragon.net (Paul Ebersman) wrote:
 > bzs> When we, The World, first began allowing the general public onto
 > bzs> the internet in October 1989 we actually had a (mildly shared*) T1
 > bzs> (1.544mbps) UUNET link. So not so bad for the time. Dial-up
 > bzs> customers shared a handful of 2400bps modems, we still have them.
 > 
 > The World was also our (UUNET) Boston hub. And at that time,
 > cross-country core backbone links were T1. We all thought the NSF T3
 > backbone was a government boon-doggle. :)

Those links were nailed up in the common closet not on 66 blocks but
basically boards with bolts and quarter-sized thumb nuts, that was New
England Telephone's (NET) demarc not our idea, it worked.

One day working with a phone guy I jokingly remarked that's some old
looking stuff, did Alexander Graham Bell put it in?

He looked at me and said "possibly, Bell founded New England Telephone
and would've helped on a job like this". The building was 1898.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Rogue objects in routing databases

[Martijn Schmidt via NANOG]

Hi Florian, NANOG,

While the symptom of (automatically) proxy registered route objects is 
problematic, perhaps we could also take this opportunity to discuss the 
underlying issue: we as an industry appear to place our trust in various IRR 
sources operated by entities that either can't or don't validate whether the 
actual owner of the involved resource approves the creation of the IRR database 
object.

We should start to push our customers to maintain their route origin 
information in databases operated by the RIR or NIR which assigned the 
resource, or even through RPKI ROAs that were optionally converted into IRR 
route objects for the ease of consumption. It's also time for the RIRs to take 
their responsibility in this matter by facilitating services like IRR, RPKI, 
PTR, etc for legacy IP space under conditions which are palatable to corporate 
lawyers, if they haven't already done so.

Finally, there doesn't have to be a global "flip the switch" day where we 
decide to stop trusting 3rd party databases, but even if we start holding 
ourselves to a higher standard one customer at a time that's still going to 
have the potential to make a big difference a couple of years down the road.

Best regards,
Martijn Schmidt

PS, a small disclaimer: none of the above are new ideas, nor did I come up with 
them myself - but it still makes sense to work towards implementing them..

From: NANOG  on behalf of Florian Brandstetter 

Sent: 25 January 2020 00:06
To: nanog@nanog.org 
Subject: Rogue objects in routing databases

It appears that there is currently an influx of rogue route
objects created within the NTTCOM and RaDB IRR databases, in
connection to Quadranet (AS8100) and China Mobile
International (CMI).

Examples of affected networks are:

193.30.32.0/23
45.129.92.0/23
45.129.94.0/24

Networks, which have seemingly no affiliation with
Quadranet, nor China Mobile International (CMI), which
merely appears to be an upstream of Quadranet and hence
creates the route objects in an automated manner.

Another person has already reached out to Quadranet to find
out the root cause of the creation of these objects. Their
support gave an ETA of 24-72 hours.

The route objects are all identical:

route:  193.30.32.0/23
descr:  CMI  (Customer Route)
origin: AS8100
mnt-by: MAINT-AS58453
changed:qas_supp...@cmi.chinamobile.com 20200117
source: RADB

There appears to be a correlation with the affected
networks, a fair share of them is part of AS-SBAG, which in
turn is part of AS-VMHAUS, which in turn is part of AS-
QUADRANET and could yield the importing of these prefixes.
AS-VMHAUS appears to be a customer of Quadranet, listed
within AS-QUADRANET-CUSTOMER-ASSET.

These networks do however have no direct connection to
Quadranet, and are not affiliated with Quadranet, nor are
currently connected to Quadranet, which, entirely ignoring
that the `origin` points to Quadranet, makes the route
object illicit.

Basically this has given AS8100, whether that be
legitimately Quadranet, or somebody impersonating/spinning
up a rogue AS8100, theoretical control over a massive amount
of prefixes, as these can be advertised without restrictions
and very likely reach a fairly high percentage of global
visibility.

--
Florian Brandstetter
President & Founder
SquareFlow Network LTD.

Re: Rogue objects in routing databases

[Job Snijders]

Hi!

This came up on our radar somewhere in the last 24 hours too. It indeed
does look very curious. Thank you for your analysis and report.

NTT is taking steps to figure out what is behind this. Our current
working theories are that perhaps the IRR maintainer account was
compromised, or some kind of automation script gone rogue, or perhaps
there is adverserial intent and this is stage setting.

I'm not sure we will be able to report our findings back to this group,
but we are actively investigating.

Kind regards,

Job

On Sat, Jan 25, 2020 at 12:06:51AM +0100, Florian Brandstetter wrote:
> It appears that there is currently an influx of rogue route
> objects created within the NTTCOM and RaDB IRR databases, in
> connection to Quadranet (AS8100) and China Mobile
> International (CMI).
> 
> Examples of affected networks are:
> 
> 193.30.32.0/23
> 45.129.92.0/23
> 45.129.94.0/24
> 
> Networks, which have seemingly no affiliation with
> Quadranet, nor China Mobile International (CMI), which
> merely appears to be an upstream of Quadranet and hence
> creates the route objects in an automated manner.
> 
> Another person has already reached out to Quadranet to find
> out the root cause of the creation of these objects. Their
> support gave an ETA of 24-72 hours.
> 
> The route objects are all identical:
> 
> route:  193.30.32.0/23
> descr:  CMI  (Customer Route)
> origin: AS8100
> mnt-by: MAINT-AS58453
> changed:qas_supp...@cmi.chinamobile.com 20200117
> source: RADB
> 
> There appears to be a correlation with the affected
> networks, a fair share of them is part of AS-SBAG, which in
> turn is part of AS-VMHAUS, which in turn is part of AS-
> QUADRANET and could yield the importing of these prefixes.
> AS-VMHAUS appears to be a customer of Quadranet, listed
> within AS-QUADRANET-CUSTOMER-ASSET.
> 
> These networks do however have no direct connection to
> Quadranet, and are not affiliated with Quadranet, nor are
> currently connected to Quadranet, which, entirely ignoring
> that the `origin` points to Quadranet, makes the route
> object illicit.
> 
> Basically this has given AS8100, whether that be
> legitimately Quadranet, or somebody impersonating/spinning
> up a rogue AS8100, theoretical control over a massive amount
> of prefixes, as these can be advertised without restrictions
> and very likely reach a fairly high percentage of global
> visibility.
> 
> --
> Florian Brandstetter
> President & Founder
> SquareFlow Network LTD.
> 

Re: Dual Homed BGP

[Baldur Norddahl]

lør. 25. jan. 2020 00.40 skrev Jon Lewis :

> On Fri, 24 Jan 2020, Baldur Norddahl wrote:
>
> > Full tables will not make much noticeable difference if you are not
> peering. However you want to make sure both
> > links get used. It can be a 90%/10% split but 100%/0% is bad because
> then you may discover that the alternate path
> > is actually broken the moment the primary fail. If you choose only
> default then you need to think about that.
> > If you join any peering exchanges, full tables will be mandatory. Some
> parties will export prefixes and then expect
> > a more specific prefix received from your transit to override a part of
> the space received via the peering.
>
> 90/10 will suck when the link carrying 90% of your traffic needs more pipe
> and you have a ton of unused capacity on the other one.  Full tables from
> both providers gives you more options to tune things (assuming outbound is
> your larger direction).  If you're an eyeball provider and most of your
> traffic is inbound, your outbound traffic routing decisions aren't quite
> as relevant.
>

If your goal is to maximize your capacity, you should run a default route
with equal cost multi path for perfect load balancing. Just beware that
there is effectively no redundancy when exceeding the capacity of a single
link.

Also consider the typical two transits each connected to a separate router,
each router handling a single circuit. I will wager that the majority of
such dual homed organisations have no idea that those two routers by
default will make different routing decisions. You get more control but you
also need the experience and talent to use it. For many it might be better
to have a solution that is understood.



> Have those suggesting "multihoming with two partial feeds and default
> routes" forgotten peering pissing matches, long lasting inter-network
> capacity issues, or that certain "tier 1" providers don't even
> have/provide a full v6 table?
>

The solution is to stay clear of tier 1 networks. Find a good local tier 3.
Whatever you are going to do, they will do better.

Regards

Baldur

Re: akamai yesterday - what in the world was that

[Paul Ebersman]

bzs> When we, The World, first began allowing the general public onto
bzs> the internet in October 1989 we actually had a (mildly shared*) T1
bzs> (1.544mbps) UUNET link. So not so bad for the time. Dial-up
bzs> customers shared a handful of 2400bps modems, we still have them.

The World was also our (UUNET) Boston hub. And at that time,
cross-country core backbone links were T1. We all thought the NSF T3
backbone was a government boon-doggle. :)

Re: Dual Homed BGP

[Octavio Alvarez]

On 1/23/20 6:01 PM, Brian wrote:
Hello all. I am having a hard time trying to articulate why a Dual Home 
ISP should have full tables. My understanding has always been that full 
tables when dual homed allow much more control. Especially in helping to 
prevent Async routes.


If you don't have full tables you will certainly have a default route 
somewhere, either set statically by you or advertised by your upstream.


Accidents may happen: your ISP may blackhole a destination; sometimes 
they adjust loads, sometimes their redundancy is not properly set up or 
they may have an otherwise incorrect BGP configuration. Sometimes they 
just mess up.


If you have full tables, you will simply stop getting the advertisements 
for the bad destinations from the bad ISP and your routers will take 
care of it because they will keep getting the advertisements from the 
other exit.


If you don't have full tables and the mistake is in a destination for 
which the default route is used, your traffic will most probably be lost 
because they don't have enough information to know a different exit and 
you may get a call at midnight. It may or may not happened to me. ;-)


Octavio.

Re: Dual Homed BGP

[Jon Lewis]

On Fri, 24 Jan 2020, Baldur Norddahl wrote:


Full tables will not make much noticeable difference if you are not peering. 
However you want to make sure both
links get used. It can be a 90%/10% split but 100%/0% is bad because then you 
may discover that the alternate path
is actually broken the moment the primary fail. If you choose only default then 
you need to think about that. 
If you join any peering exchanges, full tables will be mandatory. Some parties 
will export prefixes and then expect
a more specific prefix received from your transit to override a part of the 
space received via the peering. 


90/10 will suck when the link carrying 90% of your traffic needs more pipe 
and you have a ton of unused capacity on the other one.  Full tables from 
both providers gives you more options to tune things (assuming outbound is 
your larger direction).  If you're an eyeball provider and most of your 
traffic is inbound, your outbound traffic routing decisions aren't quite 
as relevant.


Have those suggesting "multihoming with two partial feeds and default 
routes" forgotten peering pissing matches, long lasting inter-network 
capacity issues, or that certain "tier 1" providers don't even 
have/provide a full v6 table?


If you're going to multihome, do it right, and get full routes from all 
your providers.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[Ben Cannon]

I started what became 6x7 with a 64k ISDN line.   And 9600 baud modems…   

in ’93 or so.  (I was a child, in Jr High…)

-Ben.


-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 




> On Jan 24, 2020, at 3:21 PM, b...@theworld.com wrote:
> 
> 
> On January 24, 2020 at 08:55 aar...@gvtc.com (Aaron Gould) wrote:
>> Thanks Jared, When I reminisce with my boss he reminds me that this 
>> telco/ISP here initially started with a 56kbps internet uplink , lol
> 
> Point of History:
> 
> When we, The World, first began allowing the general public onto the
> internet in October 1989 we actually had a (mildly shared*) T1
> (1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
> shared a handful of 2400bps modems, we still have them.
> 
> * It was also fanned out of our office to a handful of Boston-area
> customers who had 56kbps or 9600bps leased lines, not many.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

RE: akamai yesterday - what in the world was that

[bzs]

On January 24, 2020 at 08:55 aar...@gvtc.com (Aaron Gould) wrote:
 > Thanks Jared, When I reminisce with my boss he reminds me that this 
 > telco/ISP here initially started with a 56kbps internet uplink , lol

Point of History:

When we, The World, first began allowing the general public onto the
internet in October 1989 we actually had a (mildly shared*) T1
(1.544mbps) UUNET link. So not so bad for the time. Dial-up customers
shared a handful of 2400bps modems, we still have them.

* It was also fanned out of our office to a handful of Boston-area
customers who had 56kbps or 9600bps leased lines, not many.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Dual Homed BGP

[Blake Hudson]

On 1/23/2020 6:01 PM, Brian wrote:
Hello all. I am having a hard time trying to articulate why a Dual 
Home ISP should have full tables. My understanding has always been 
that full tables when dual homed allow much more control. Especially 
in helping to prevent Async routes.


Brian, you're correct that having more routing information will give you 
more control over routing decisions. However, for me, it's not about 
control/traffic engineering but about basic redundancy/availability. 
Taking full tables gives you visibility into whether an actual path 
exists (or does not exist) via each of your upstream providers. If you 
just take a default route originated by your peer you'll only have 
visibility that there's a connection between your router and your peer - 
not to the rest of the internet or to a specific destination past your 
peer. As Job said, maintenance, router reboots, and other upstream 
connectivity issues can cause an upstream peer to be missing routes that 
the other peer might have.


In my experience, most folks multi-home for improved 
redundancy/availability. So for those that are multi-homed, I recommend 
taking full tables so that you can get the most benefit. This may come 
at an additional expense so I understand why some would choose to take a 
default route only.


--Blake

Rogue objects in routing databases

[Florian Brandstetter]

It appears that there is currently an influx of rogue route
objects created within the NTTCOM and RaDB IRR databases, in
connection to Quadranet (AS8100) and China Mobile
International (CMI).

Examples of affected networks are:

193.30.32.0/23
45.129.92.0/23
45.129.94.0/24

Networks, which have seemingly no affiliation with
Quadranet, nor China Mobile International (CMI), which
merely appears to be an upstream of Quadranet and hence
creates the route objects in an automated manner.

Another person has already reached out to Quadranet to find
out the root cause of the creation of these objects. Their
support gave an ETA of 24-72 hours.

The route objects are all identical:

route:  193.30.32.0/23
descr:  CMI  (Customer Route)
origin: AS8100
mnt-by: MAINT-AS58453
changed:qas_supp...@cmi.chinamobile.com 20200117
source: RADB

There appears to be a correlation with the affected
networks, a fair share of them is part of AS-SBAG, which in
turn is part of AS-VMHAUS, which in turn is part of AS-
QUADRANET and could yield the importing of these prefixes.
AS-VMHAUS appears to be a customer of Quadranet, listed
within AS-QUADRANET-CUSTOMER-ASSET.

These networks do however have no direct connection to
Quadranet, and are not affiliated with Quadranet, nor are
currently connected to Quadranet, which, entirely ignoring
that the `origin` points to Quadranet, makes the route
object illicit.

Basically this has given AS8100, whether that be
legitimately Quadranet, or somebody impersonating/spinning
up a rogue AS8100, theoretical control over a massive amount
of prefixes, as these can be advertised without restrictions
and very likely reach a fairly high percentage of global
visibility.

--
Florian Brandstetter
President & Founder
SquareFlow Network LTD.

Re: Dual Homed BGP

[Baldur Norddahl]

Full tables will not make much noticeable difference if you are not
peering. However you want to make sure both links get used. It can be a
90%/10% split but 100%/0% is bad because then you may discover that the
alternate path is actually broken the moment the primary fail. If you
choose only default then you need to think about that.

If you join any peering exchanges, full tables will be mandatory. Some
parties will export prefixes and then expect a more specific prefix
received from your transit to override a part of the space received via the
peering.

Regards

Baldur


fre. 24. jan. 2020 17.41 skrev Brian :

> Hello all. I am having a hard time trying to articulate why a Dual Home
> ISP should have full tables. My understanding has always been that full
> tables when dual homed allow much more control. Especially in helping to
> prevent Async routes.
>
>
> Am I crazy?
>

Re: Data on latency and loss-rates during congestion DDoS attacks

[Damian Menscher via NANOG]

I suggest testing with a broad variety of values, as losses as low as 5%
can be annoying, but losses at 50% or more are not uncommon.

Damian

On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg  wrote:

> Dear NANOG,
>
> One of my ongoing research works is about a transport protocol that
> ensures (critical) communication in spite of DDoS congestion attack (which
> cannot be circumvented), by (careful) use of Forward Error Correction. Yes,
> obviously, this has to be done and used carefully since the FEC clearly
> increases traffic rather than the typical congestion-control approach of
> reducing it, I'm well aware of it; but some applications are critical (and
> often low-bandwidth) so such tool is important.
>
> I am looking for data on loss rate and congestion of DDoS attacks to make
> sure we use right parameters. Any chance you have such data and can share?
>
> Many thanks!
> --
> Amir Herzberg
> Comcast chair of security innovation, University of Connecticut
> Foundations of cybersecurity
> ,
>  part
> I (see also part II and presentations):
> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises
> 
>
>
>

Re: Dual Homed BGP

[Gavin Henry]

Don't forget to connect to peering exchanges and take their full routes too
if you can.

Re: Dual Homed BGP

[Jay Hennigan]

On 1/23/20 16:01, Brian wrote:
Hello all. I am having a hard time trying to articulate why a Dual Home 
ISP should have full tables. My understanding has always been that full 
tables when dual homed allow much more control. Especially in helping to 
prevent Async routes.


If you're multi-homed you'll have some asymmetric routes. Even if you 
aren't, they'll be asymmetric to your upstream. It's easy to manipulate 
which path traffic leaving your site takes, difficult or impossible to 
manipulate via which path it enters.


If you have sufficient horsepower and memory in your routers, taking 
full tables won't hurt anything and will help in situations where one of 
your upstreams loses reachability to a destination. For 
belt-and-suspenders, take full routes plus a default.



Am I crazy?


Perhaps, but if so it has little if any relationship to the size of the 
BGP tables in your border routers.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: akamai yesterday - what in the world was that

[Valdis Klētnieks]

On Fri, 24 Jan 2020 08:55:12 -0600, "Aaron Gould" said:
> Thanks Jared, When I reminisce with my boss he reminds me that this telco/ISP
> here initially started with a 56kbps internet uplink , lol

I remember when a "gateway" was a Microvax II with an ethernet card and a
bisync card, and fuzzballs were the big thing, and the other end of your
connection was either Arpanet or Milnet, and RFCs specified octects for a
reason



pgp52sAiFUVQr.pgp
Description: PGP signature

RE: akamai yesterday - what in the world was that

[Gene LeDuc]

There is probably a "law" enshrined somewhere: Bandwidth is like closet 
space, demand will always manage to exceed capacity.


Gene

On 1/24/20 6:52 AM, Aaron Gould wrote:
Thanks Hugo, very interesting.  Induced demand.  Someone said recently… 
they’ve seen that no matter how much bandwidth you give a customer, they 
will eventually figure out how to use it. (whether they realize it or 
not… I guess it just happens)


-Aaron

*From:*NANOG [mailto:nanog-boun...@nanog.org] *On Behalf Of *Hugo Slabbert
*Sent:* Thursday, January 23, 2020 11:44 AM
*To:* Tom Beecher
*Cc:* NANOG list
*Subject:* Re: akamai yesterday - what in the world was that

 > This just follows the same rules as networks have always seemed to; 
If you build it, they will come, and you'll have to build more. :)


https://en.m.wikipedia.org/wiki/Induced_demand

:-)

On Thu., Jan. 23, 2020, 09:40 Tom Beecher  wrote:

I think this is a tribute to how we’ve built and upgraded
networks for capacity and speed.

I think it's spot on.

In years past it made more sense to distribute smaller , incremental
patches. More work on the software side, but it was likely a better
option than getting blasted on Twitter because "OMG I WANT TO PLAY
AND MY DOWNLOAD IS TAKING 8 HOURS".

This just follows the same rules as networks have always seemed to;
If you build it, they will come, and you'll have to build more. :)

On Thu, Jan 23, 2020 at 11:57 AM Jared Mauch mailto:ja...@puck.nether.net>> wrote:



 > On Jan 23, 2020, at 11:52 AM, Valdis Klētnieks
mailto:valdis.kletni...@vt.edu>> wrote:
 >
 > On Thu, 23 Jan 2020 17:13:15 +0100, Bryan Holloway said:
 >
 >> Game releases are hardly a new thing, but these last two
events seem to
 >> be almost an order of magnitude higher than what we're used
to (at least
 >> on our predominantly eyeball network.)
 >>
 >> Any thoughts from the community? We're taking steps to
accommodate, but
 >> from a capacity-planning perspective, this seems non-linear
to me.
 >
 > Be prepared for an entire new world of hurt this holiday
season. Sony has already
 > confirmed that PS5 releases will ship on 100Gbyte blu-ray
disks.  Which means that
 > download sizes will be comparable…

There’s also the “we will stream you all the data things” I keep
hearing about like the
Consoles without discs or some other thing I can’t remember the
name of.

I think this is a tribute to how we’ve built and upgraded
networks for capacity and speed.

- Jared



--
Gene LeDuc | A little learning is a dangerous thing,
Technology Security| but a lot of ignorance is just as bad.
San Diego State University |   --Bob Edwards

Re: Dual Homed BGP

[Chriztoffer Hansen]

fre. 24. jan. 2020 18.23 skrev Job Snijders :

>
> On Fri, 24 Jan 2020 at 17:40, Brian  wrote:
>
> Am I crazy?
>>
>
> I dropped out of university, never completed my psychology studies, I fear
> I am unqualified to answer this question. ;-)
>

Education shopping, it is called by some.

Chriztoffer

>

Re: akamai yesterday - what in the world was that

[Hugo Slabbert]

Same with compute resources, tbh. Give 'em a new stack of racks: "Oh, this
service that didn't even exist last year now requires 10,000 CPU cores
kthxbye."

Also, https://twitter.com/iamdevloper/status/926458505355235328?s=20

"1969:
-what're you doing with that 2KB of RAM?
-sending people to the moon

2017:
-what're you doing with that 1.5GB of RAM?
-running Slack"

On Fri., Jan. 24, 2020, 06:52 Aaron Gould  wrote:

> Thanks Hugo, very interesting.  Induced demand.  Someone said recently…
> they’ve seen that no matter how much bandwidth you give a customer, they
> will eventually figure out how to use it. (whether they realize it or not…
> I guess it just happens)
>
>
>
> -Aaron
>
>
>
> *From:* NANOG [mailto:nanog-boun...@nanog.org] *On Behalf Of *Hugo
> Slabbert
> *Sent:* Thursday, January 23, 2020 11:44 AM
> *To:* Tom Beecher
> *Cc:* NANOG list
> *Subject:* Re: akamai yesterday - what in the world was that
>
>
>
> > This just follows the same rules as networks have always seemed to; If
> you build it, they will come, and you'll have to build more. :)
>
>
>
> https://en.m.wikipedia.org/wiki/Induced_demand
>
>
>
> :-)
>
>
>
>
>
> On Thu., Jan. 23, 2020, 09:40 Tom Beecher  wrote:
>
> I think this is a tribute to how we’ve built and upgraded networks for
> capacity and speed.
>
>
>
> I think it's spot on.
>
>
>
> In years past it made more sense to distribute smaller , incremental
> patches. More work on the software side, but it was likely a better option
> than getting blasted on Twitter because "OMG I WANT TO PLAY AND MY DOWNLOAD
> IS TAKING 8 HOURS".
>
>
>
> This just follows the same rules as networks have always seemed to; If you
> build it, they will come, and you'll have to build more. :)
>
>
>
> On Thu, Jan 23, 2020 at 11:57 AM Jared Mauch 
> wrote:
>
>
>
> > On Jan 23, 2020, at 11:52 AM, Valdis Klētnieks 
> wrote:
> >
> > On Thu, 23 Jan 2020 17:13:15 +0100, Bryan Holloway said:
> >
> >> Game releases are hardly a new thing, but these last two events seem to
> >> be almost an order of magnitude higher than what we're used to (at least
> >> on our predominantly eyeball network.)
> >>
> >> Any thoughts from the community? We're taking steps to accommodate, but
> >> from a capacity-planning perspective, this seems non-linear to me.
> >
> > Be prepared for an entire new world of hurt this holiday season. Sony
> has already
> > confirmed that PS5 releases will ship on 100Gbyte blu-ray disks.  Which
> means that
> > download sizes will be comparable…
>
> There’s also the “we will stream you all the data things” I keep hearing
> about like the
> Consoles without discs or some other thing I can’t remember the name of.
>
> I think this is a tribute to how we’ve built and upgraded networks for
> capacity and speed.
>
> - Jared
>
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 25 Jan, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  792806
Prefixes after maximum aggregation (per Origin AS):  301689
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  387892
Total ASes present in the Internet Routing Table: 66795
Prefixes per ASN: 11.87
Origin-only ASes present in the Internet Routing Table:   57383
Origin ASes announcing only one prefix:   24135
Transit ASes present in the Internet Routing Table:9412
Transit-only ASes present in the Internet Routing Table:291
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  34
Max AS path prepend of ASN (206156)  26
Prefixes from unregistered ASNs in the Routing Table:  1310
Number of instances of unregistered ASNs:  1310
Number of 32-bit ASNs allocated by the RIRs:  30286
Number of 32-bit ASNs visible in the Routing Table:   24906
Prefixes from 32-bit ASNs in the Routing Table:  114350
Number of bogon 32-bit ASNs visible in the Routing Table:20
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:895
Number of addresses announced to Internet:   2852684672
Equivalent to 170 /8s, 8 /16s and 131 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.4
Total number of prefixes smaller than registry allocations:  265507

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   210634
Total APNIC prefixes after maximum aggregation:   61288
APNIC Deaggregation factor:3.44
Prefixes being announced from the APNIC address blocks:  204262
Unique aggregates announced from the APNIC address blocks:84939
APNIC Region origin ASes present in the Internet Routing Table:   10299
APNIC Prefixes per ASN:   19.83
APNIC Region origin ASes announcing only one prefix:   2849
APNIC Region transit ASes present in the Internet Routing Table:   1546
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5357
Number of APNIC addresses announced to Internet:  768077056
Equivalent to 45 /8s, 199 /16s and 237 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:233323
Total ARIN prefixes after maximum aggregation:   107360
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   231005
Unique aggregates announced from the ARIN address blocks:116626
ARIN Region origin ASes present in the Internet Routing Table:18389
ARIN Prefixes per ASN:12.56
ARIN 

Looking for topology validation

[Kévin Vermeulen]

Hi NANOG,

Sorry for multiple sendings.

First of all, thanks to the operators that have contributed to our survey,
we will acknowledge you publicly.

I just resend the message one last time, hoping to get some more feedback.

Our teams at Sorbonne Université and Naval Postgraduate School have
developed a new Internet topology mapping tool, Diamond-Miner.

Diamond-Miner[3] combines Paris Traceroute Multipath Detection Algorithm[1]
and high probing rate Yarrp[2] techniques to trace the load balanced paths
at Internet Scale.

We are seeking now some validation of our inferences, in particular the
traceroutes links that we have found.

We have developed a small website for operators to provide validation:
http://heartbeat.planet-lab.eu:8000

You can either publicly submit the validation on the website or send us an
email to kevin.vermeu...@sorbonne-universite.fr .

You will find all the details on the website, do not hesitate to ask if you
have further questions.

Thanks in advance,

Kevin

[1]: https://arxiv.org/pdf/1809.10070
[2]: http://rbeverly.net/research/papers/yarrp-imc16.pdf
[3]: https://www.usenix.org/conference/nsdi20/accepted-papers

Re: Dual Homed BGP

[Job Snijders]

Dear Brian,

On Fri, 24 Jan 2020 at 17:40, Brian  wrote:

> Hello all. I am having a hard time trying to articulate why a Dual Home
> ISP should have full tables. My understanding has always been that full
> tables when dual homed allow much more control. Especially in helping to
> prevent Async routes.
>

The advantage of receiving full routing tables from both providers is that
in cases where one of the two providers is not yet fully converged, your
routers will use the other provider for those missing destinations. This
may happen during maintenance or router boot-up in your upstream’s network.

Another advantage of receiving full routes is that you can manipulate
LOCAL_PREF per destination, or compose routing policy based on per-route
attributes such as BGP communities your upstreams set. It can happen that a
provider is great for 99% of destinations, except a few - without full
tables such granular traffic-engineering can be cumbersome.

Virtually all internet routing is asymmetric, I wouldn’t consider that an
issue.

Am I crazy?
>

I dropped out of university, never completed my psychology studies, I fear
I am unqualified to answer this question. ;-)

Kind regards,

Job

Re: Dual Homed BGP

[Cummings, Chris]

We have full tables from 2 ISPs at just one datacenter, and it is nice in the 
case of partial reachability issues—If one ISP loses access to routes to a 
destination but the other one doesn’t, for example. For us, the decision to do 
full tables was easy, as we are running 2 MX150s which can very easily handle 
the load and convergence is still less than a minute or so. As far as optimal 
path goes, full tables really doesn't help us much, so we made sure to get 
matching speed circuits just to make things simple. We have AT and 
CenturyLink, and most things prefer CenturyLink as they are pretty well peered 
due to all of their acquisitions. It would be interesting to see a distribution 
plot of ASPATH length, I would bet that a huge chunk  of our routes are only 
2-3 hops away.

/chris
 

On 1/24/20, 10:56, "NANOG on behalf of Ben Cannon"  wrote:

Honestly, this.  Your only real choice is what of 2 pipes to chuck it out 
of.

Full tables vs partial and a default don’t make the process much more 
intelligent for 1 site dual homed, and as mentioned routing policy will have 
more influence.

-Ben

> On Jan 24, 2020, at 8:47 AM, Mel Beckman  wrote:
> 
> It’s pretty pointless for a small ISP to get full routes, because the BGP 
tables are so highly manipulated. It’s better to just get “company” routes for 
each upstream, and then use your own traffic engineering via prepending and 
static or policy routes to balance the outbound traffic the way you like. 
> 
> -mel 
> 
>> On Jan 24, 2020, at 8:40 AM, Brian  wrote:
>> 
>> 
>> Hello all. I am having a hard time trying to articulate why a Dual Home 
ISP should have full tables. My understanding has always been that full tables 
when dual homed allow much more control. Especially in helping to prevent Async 
routes.
>> 
>> 
>> Am I crazy? 

Re: Dual Homed BGP

[Ben Cannon]

Honestly, this.  Your only real choice is what of 2 pipes to chuck it out of.

Full tables vs partial and a default don’t make the process much more 
intelligent for 1 site dual homed, and as mentioned routing policy will have 
more influence.

-Ben

> On Jan 24, 2020, at 8:47 AM, Mel Beckman  wrote:
> 
> It’s pretty pointless for a small ISP to get full routes, because the BGP 
> tables are so highly manipulated. It’s better to just get “company” routes 
> for each upstream, and then use your own traffic engineering via prepending 
> and static or policy routes to balance the outbound traffic the way you like. 
> 
> -mel 
> 
>> On Jan 24, 2020, at 8:40 AM, Brian  wrote:
>> 
>> 
>> Hello all. I am having a hard time trying to articulate why a Dual Home ISP 
>> should have full tables. My understanding has always been that full tables 
>> when dual homed allow much more control. Especially in helping to prevent 
>> Async routes.
>> 
>> 
>> Am I crazy? 

Re: Dual Homed BGP

[Mel Beckman]

It’s pretty pointless for a small ISP to get full routes, because the BGP 
tables are so highly manipulated. It’s better to just get “company” routes for 
each upstream, and then use your own traffic engineering via prepending and 
static or policy routes to balance the outbound traffic the way you like. 

 -mel 

> On Jan 24, 2020, at 8:40 AM, Brian  wrote:
> 
> 
> Hello all. I am having a hard time trying to articulate why a Dual Home ISP 
> should have full tables. My understanding has always been that full tables 
> when dual homed allow much more control. Especially in helping to prevent 
> Async routes.
> 
> 
> Am I crazy? 

Need a contact at Telefonica Peru AS6147

[Marco Marletta]

Anyone at Telefonica Peru AS6147 please contact me off list ASAP

nancy.cord...@telefonica.com already contacted with no luck

thank you,

Marco

--
Marco Marletta
~
GARR - The Italian Academic and Research Network
Via dei Tizii, 6 I-00185 Rome - Italy
office: +39 06 4962 2000 fax: +39 06 4962 2044
Email: marco.marle...@garr.it
~

Dual Homed BGP

[Brian]

Hello all. I am having a hard time trying to articulate why a Dual Home ISP
should have full tables. My understanding has always been that full tables
when dual homed allow much more control. Especially in helping to prevent
Async routes.


Am I crazy?

RE: akamai yesterday - what in the world was that

[Aaron Gould]

A hahahaha, that's great Warren !

afterall, it is Friday, might was well...

oh my gosh, I cut my teeth on a few of those mgs type routers... I recall they 
sounded a bit like a small vacuum cleaner and I think I had to set jumpers 
or flip dip switches for password recovery!
https://www.flickr.com/photos/pleia2/16858944610

back then, my onion hung on a rope around my waist 

-Aaron

Re: akamai yesterday - what in the world was that

[Warren Kumari]

On Fri, Jan 24, 2020 at 9:55 AM Aaron Gould  wrote:
>
> Thanks Jared, When I reminisce with my boss he reminds me that this telco/ISP 
> here initially started with a 56kbps internet uplink , lol

Oh, gods, what have you done?! This comment will bring everyone out of
the woodwork, reminiscing about the good ol' days

So, I grew up in South Africa, and one of the more fascinating /
cooler things I saw was a modem which would get you ~50bps (bps, not
Kbps) over a single strand of barbed wire -- you'd hammer a largish
nail into the ground, and clip one alligator[0] clip onto that, and
another alligator clip onto the barbed wire. Repeat the process on the
other side (up to ~5km away), plug the modems in, and bits would
flow... I only saw these used a few times, but always thought they
were cool

One of the first ISPs I worked at had an AGS+ as the "core" router
(and a pile of IGS's) -- the AGS had metal plate in the front to
access the "line cards", and a monster big squirrel fan - the squirrel
fan was strong enough that the vacuum / airflow would keep the metal
plate sucked on if you didn't do up the screw.. anyway, the device
also had a watchdog timer, which would reboot the box if IOS[1] locked
up, and the fan would slow down while this occurred -- so, for a long
time, our fastest / most reliable monitoring was an empty PC case
placed on the floor under the rack -- when the router locked up, the
fan would slow down, the front would fall off[2] and bounce on the PC
case, making an unholy racket - and alerting the NOC that something
bad was happening

Anyway, so I tied an onion to my belt, which was the style at the
time. Now, to take the ferry cost a nickel, and in those days, nickels
had pictures of bumblebees on 'em. Give me five bees for a quarter,
you'd say.
Now where were we? Oh yeah: the important thing was I had an onion on
my belt, which was the style at the time. They didn't have white
onions because of the war. The only thing you could get was those big
yellow ones...

W
[0]: In .za we called them crocodile clips -- true story.
[1]: For all you young whippersnappers, that's the Cisco IOS, not the
Apple iOS.. :-/
[2]: https://www.youtube.com/watch?v=3m5qxZm_JqM -- Unlike the rest of
this email, this is off-topic, but still great

>
> -Aaron
>
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

RE: akamai yesterday - what in the world was that

[Aaron Gould]

Thanks Jared, When I reminisce with my boss he reminds me that this telco/ISP 
here initially started with a 56kbps internet uplink , lol

-Aaron

RE: akamai yesterday - what in the world was that

[Aaron Gould]

Thanks Hugo, very interesting.  Induced demand.  Someone said recently… they’ve 
seen that no matter how much bandwidth you give a customer, they will 
eventually figure out how to use it. (whether they realize it or not… I guess 
it just happens)

 

-Aaron

 

From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Hugo Slabbert
Sent: Thursday, January 23, 2020 11:44 AM
To: Tom Beecher
Cc: NANOG list
Subject: Re: akamai yesterday - what in the world was that

 

> This just follows the same rules as networks have always seemed to; If you 
> build it, they will come, and you'll have to build more. :)

 

https://en.m.wikipedia.org/wiki/Induced_demand

 

:-)

 

 

On Thu., Jan. 23, 2020, 09:40 Tom Beecher  wrote:

I think this is a tribute to how we’ve built and upgraded networks for capacity 
and speed.

 

I think it's spot on. 

 

In years past it made more sense to distribute smaller , incremental patches. 
More work on the software side, but it was likely a better option than getting 
blasted on Twitter because "OMG I WANT TO PLAY AND MY DOWNLOAD IS TAKING 8 
HOURS". 

 

This just follows the same rules as networks have always seemed to; If you 
build it, they will come, and you'll have to build more. :) 

 

On Thu, Jan 23, 2020 at 11:57 AM Jared Mauch  wrote:



> On Jan 23, 2020, at 11:52 AM, Valdis Klētnieks  
> wrote:
> 
> On Thu, 23 Jan 2020 17:13:15 +0100, Bryan Holloway said:
> 
>> Game releases are hardly a new thing, but these last two events seem to
>> be almost an order of magnitude higher than what we're used to (at least
>> on our predominantly eyeball network.)
>> 
>> Any thoughts from the community? We're taking steps to accommodate, but
>> from a capacity-planning perspective, this seems non-linear to me.
> 
> Be prepared for an entire new world of hurt this holiday season. Sony has 
> already
> confirmed that PS5 releases will ship on 100Gbyte blu-ray disks.  Which means 
> that
> download sizes will be comparable…

There’s also the “we will stream you all the data things” I keep hearing about 
like the
Consoles without discs or some other thing I can’t remember the name of.

I think this is a tribute to how we’ve built and upgraded networks for capacity 
and speed.

- Jared

RE: akamai yesterday - what in the world was that

[Aaron Gould]

Interesting… I just found this.  Speaks of 800 gbps, 1.2 tbps, 1.6 tbps Ethernet

 

https://en.wikipedia.org/wiki/Terabit_Ethernet

 

https://ethernetalliance.org/technology/2019-roadmap/

 

https://ethernetalliance.org/wp-content/uploads/2019/08/EthernetRoadmap-2019-Side1-ToPrint.pdf

 

https://ethernetalliance.org/wp-content/uploads/2019/08/EthernetRoadmap-2019-Side2-ToPrint.pdf

 

-Aaron

 

From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of jdambro...@gmail.com
Sent: Thursday, January 23, 2020 11:42 AM
To: 'Tom Beecher'; 'Jared Mauch'
Cc: 'NANOG list'
Subject: RE: akamai yesterday - what in the world was that

 

Love it Love it Love it

 

I have been telling people that the IEEE 802.3 Ethernet Working Group needs to 
start looking beyond 400 Gb/s Ethernet.  It’s only a matter of time where we 
will need it!

 

From: NANOG  On Behalf Of Tom Beecher
Sent: Thursday, January 23, 2020 6:39 PM
To: Jared Mauch 
Cc: NANOG list 
Subject: Re: akamai yesterday - what in the world was that

 

I think this is a tribute to how we’ve built and upgraded networks for capacity 
and speed.

 

I think it's spot on. 

 

In years past it made more sense to distribute smaller , incremental patches. 
More work on the software side, but it was likely a better option than getting 
blasted on Twitter because "OMG I WANT TO PLAY AND MY DOWNLOAD IS TAKING 8 
HOURS". 

 

This just follows the same rules as networks have always seemed to; If you 
build it, they will come, and you'll have to build more. :) 

 

On Thu, Jan 23, 2020 at 11:57 AM Jared Mauch  wrote:



> On Jan 23, 2020, at 11:52 AM, Valdis Klētnieks  
> wrote:
> 
> On Thu, 23 Jan 2020 17:13:15 +0100, Bryan Holloway said:
> 
>> Game releases are hardly a new thing, but these last two events seem to
>> be almost an order of magnitude higher than what we're used to (at least
>> on our predominantly eyeball network.)
>> 
>> Any thoughts from the community? We're taking steps to accommodate, but
>> from a capacity-planning perspective, this seems non-linear to me.
> 
> Be prepared for an entire new world of hurt this holiday season. Sony has 
> already
> confirmed that PS5 releases will ship on 100Gbyte blu-ray disks.  Which means 
> that
> download sizes will be comparable…

There’s also the “we will stream you all the data things” I keep hearing about 
like the
Consoles without discs or some other thing I can’t remember the name of.

I think this is a tribute to how we’ve built and upgraded networks for capacity 
and speed.

- Jared

Data on latency and loss-rates during congestion DDoS attacks

[Amir Herzberg]

Dear NANOG,

One of my ongoing research works is about a transport protocol that ensures
(critical) communication in spite of DDoS congestion attack (which cannot
be circumvented), by (careful) use of Forward Error Correction. Yes,
obviously, this has to be done and used carefully since the FEC clearly
increases traffic rather than the typical congestion-control approach of
reducing it, I'm well aware of it; but some applications are critical (and
often low-bandwidth) so such tool is important.

I am looking for data on loss rate and congestion of DDoS attacks to make
sure we use right parameters. Any chance you have such data and can share?

Many thanks!
-- 
Amir Herzberg
Comcast chair of security innovation, University of Connecticut
Foundations of cybersecurity
,
part
I (see also part II and presentations):
https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises

Re: akamai yesterday - what in the world was that

[Niels Bakker]

* xima...@gmail.com (Töma Gavrichenkov) [Fri 24 Jan 2020, 11:49 CET]:

And now for our amusement Akamai can do it *accidentally*.


What do you mean?  The CDNs don't publish the games nor do they buy 
the games.  The people downloading aren't even their customers.  The 
publishers generally decide the % of traffic share each CDN serves 
if they contract with multiple CDNs for a project.



-- Niels.

Re: digitalelement.com GeoIP?

[M. Omer GOLGELI]

You may try to check and reach InfoSniper instead.

https://community.hulu.com/s/idea/0871L00V3ntQAC/detail 
(https://community.hulu.com/s/idea/0871L00V3ntQAC/detail)
M. Omer GOLGELI
---
AS202365

 https://as202365.peeringdb.com (https://as202365.peeringdb.com)
 https://bgp.he.net/AS202365 (https://bgp.he.net/AS202365)

NOC:
 Phone: +90-533-2600533
 Email: o...@chronos.com.tr (mailto:o...@chronos.com.tr)
January 24, 2020 11:21 AM, "Justin Wilson" mailto:li...@mtin.net?to=%22Justin%20Wilson%22%20)> wrote:
Has anyone have a contact with digitalelement.com (http://digitalelement.com) 
and their GeoIP stuff? We received a new ipv4 block from ARIN last week and 
HULU tells digitalelement.com (http://digitalelement.com) is who they use. Our 
new block is not being coded correctly. I can not find any sort of technical 
contact on the Digital Element web-site. It’s all marketing stuff.
Any help would be appreciated. 
 Justin Wilson j...@mtin.net (mailto:j...@mtin.net)  —  https://j2sw.com 
(https://j2sw.com) - All things jsw (AS209109)  https://blog.j2sw.com 
(https://blog.j2sw.com) - Podcast and Blog

Re: akamai yesterday - what in the world was that

[Töma Gavrichenkov]

On Fri, Jan 24, 2020, 1:45 PM Simon Leinen  wrote:

> For your amusement, this latest e-bloodbath, erm -sports update, at 48GB
> ("PC" version), would take about 463 days (~15 months) to complete at
> 9600 bps (not counting overhead like packet headers etc.)
>

And now for our amusement Akamai can do it *accidentally*.

--
Töma

>

Re: akamai yesterday - what in the world was that

[Simon Leinen]

Paul Nash writes:
> A bit of perspective on bandwidth and feeling old.  The first
> non-academic connection from Africa (Usenet and Email, pre-Internet)
> ran at about 9600 bps over a Telebit Trailblazer in my living room.

For your amusement, this latest e-bloodbath, erm -sports update, at 48GB
("PC" version), would take about 463 days (~15 months) to complete at
9600 bps (not counting overhead like packet headers etc.)

At 64kbps (ISDN/Antarctica) you could do it in 69 days, maybe even
finishing before the next - undoubtedly bigger - release comes out.
-- 
Simon.
[I conservatively used decimal Gigabytes, not "Gibibytes" - at 48GiB the
 numbers would be 497 or 74.5 days respectively.]

digitalelement.com GeoIP?

[Justin Wilson]

Has anyone have a contact with digitalelement.com  
and their GeoIP stuff? We received a new ipv4 block from ARIN last week and 
HULU tells digitalelement.com  is who they use.  
Our new block is not being coded correctly.  I can not find any sort of 
technical contact on the Digital Element web-site.  It’s all marketing stuff.  

Any help would be appreciated.


Justin Wilson
j...@mtin.net

—
https://j2sw.com - All things jsw (AS209109)
https://blog.j2sw.com - Podcast and Blog