Re: Special Counsel Office report web site

[mike . lyon]

Deal. 

Though, like you, i am assuming it’ll just be another day on the intarwebs as 
well...

We shall see!


-Mike

> On Apr 17, 2019, at 21:25, Martin Hannigan  wrote:
> 
> Hey Mike.
> 
> Agreed. But the scale of a 400 page document with global interest? Should
> be highly cached with a good ratio of served to pull bits. I'm willing to
> bet you a beer its just another day on the Internet. However, I could be
> wrong. Hope to see you in DC to collect! I already know Brett is in. :)
> 
> Best,
> 
> -M<
> 

Re: Special Counsel Office report web site

[Martin Hannigan]

Hey Mike.

Agreed. But the scale of a 400 page document with global interest? Should
be highly cached with a good ratio of served to pull bits. I'm willing to
bet you a beer its just another day on the Internet. However, I could be
wrong. Hope to see you in DC to collect! I already know Brett is in. :)

Best,

-M<



On Thu, Apr 18, 2019 at 12:21 AM  wrote:

> Oh spiffy!
>
> Will be interesting to see if there are any problems then.
>
> -Mike
>
> On Apr 17, 2019, at 21:14, Brett Watson  wrote:
>
> Or maybe do this (faster than nanog archives) :)
>
>
> bash-3.2# dig cia.gov ns
>
> ; <<>> DiG 9.10.6 <<>> cia.gov ns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;cia.gov. IN NS
>
> ;; ANSWER SECTION:
> cia.gov. 86400 IN NS a22-66.akam.net.
> cia.gov. 86400 IN NS a16-67.akam.net.
> cia.gov. 86400 IN NS a1-22.akam.net.
> cia.gov. 86400 IN NS a12-65.akam.net.
> cia.gov. 86400 IN NS a3-64.akam.net.
> cia.gov. 86400 IN NS a13-65.akam.net.
>
>
>
> On Apr 17, 2019, at 9:11 PM, Martin Hannigan  wrote:
>
>
> Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It
> certainly is.
>
>
>
> On Wed, Apr 17, 2019 at 23:34  wrote:
>
>> Isn’t this why god invented CDNs? Though, i doubt the govment is
>> Akamized...
>>
>> -Mike
>>
>> On Apr 17, 2019, at 20:26, Mark Seiden  wrote:
>>
>> of course p2p is the way to distribute this but i doubt the justice
>> department can admit there is any positive legitimate use for p2p.
>>
>> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent
>> yet.  “russiar, are you listening?”)
>>
>> (i sure hope there’s a signed version or at least a hash.)
>>
>> i predict there will be versions with fake content, missing content, and
>> malware inserted that are distributed as well.
>>
>>
>>
>>
>> and i’ll bet there will be some infected pdf version as well distributed
>> that way.
>> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG ,
>> wrote:
>>
>> And we may still see the web stack being the ultimate cause of the delay.
>>
>>
>> Parkinson's law always comes to the rescue:-)
>> More faster and efficient processing architecture, Hyper transport buses,
>> amd-64 Branch prediction.
>> Massively faster storage subsystems and disk arrays, SSD slab caching for
>> hypervisors
>>
>> And some dude with a AJAX framework to serve a PDF bringging the whole
>> thing to a a screeching halt
>>
>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
>>
>> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
>>
>> Things will probably be easier this time. The Internet has evolved
>>
>> ways
>>
>> of dealing with exactly this problem. (Avi used to call it “slash-dot
>>
>>
>> insurance”, but the idea is the same.) Specifically:
>>
>>
>> Yep, it will be interesting to see where the chokepoints are tommorrow.
>>
>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>>
>> TCP and Web stacks. Eventually the Associated Press got a copy of the
>> Starr Report on a CD from a congressional staffer. The press intern
>> running down the street holding a CD was faster than 1998 internet :-)
>>
>> We were also lucky in 1998, no one had thought of DDOS yet.
>>
>>
>> Frederick Wessling (CIO)
>> Succinct Systems LLC
>> Cell: +1(561) 571-2799
>> Office: +1(904) 758-9915 ext. 9925
>> Fax: +1(904) 758-9987
>> www.SuccinctSystems.com 
>>
>>
>

Re: Special Counsel Office report web site

[mike . lyon]

Oh spiffy! 

Will be interesting to see if there are any problems then.

-Mike

> On Apr 17, 2019, at 21:14, Brett Watson  wrote:
> 
> Or maybe do this (faster than nanog archives) :) 
> 
> 
> bash-3.2# dig cia.gov ns
> 
> ; <<>> DiG 9.10.6 <<>> cia.gov ns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;cia.gov. IN  NS
> 
> ;; ANSWER SECTION:
> cia.gov.  86400   IN  NS  a22-66.akam.net.
> cia.gov.  86400   IN  NS  a16-67.akam.net.
> cia.gov.  86400   IN  NS  a1-22.akam.net.
> cia.gov.  86400   IN  NS  a12-65.akam.net.
> cia.gov.  86400   IN  NS  a3-64.akam.net.
> cia.gov.  86400   IN  NS  a13-65.akam.net.
> 
> 
> 
>> On Apr 17, 2019, at 9:11 PM, Martin Hannigan  wrote:
>> 
>> 
>> Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It 
>> certainly is. 
>> 
>> 
>> 
>>> On Wed, Apr 17, 2019 at 23:34  wrote:
>>> Isn’t this why god invented CDNs? Though, i doubt the govment is Akamized...
>>> 
>>> -Mike
>>> 
 On Apr 17, 2019, at 20:26, Mark Seiden  wrote:
 
 of course p2p is the way to distribute this but i doubt the justice 
 department can admit there is any positive legitimate use for p2p.
 
 (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent 
 yet.  “russiar, are you listening?”)
 
 (i sure hope there’s a signed version or at least a hash.)
 
 i predict there will be versions with fake content, missing content, and 
 malware inserted that are distributed as well.
 
 
 
 
 and i’ll bet there will be some infected pdf version as well distributed 
 that way.
> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , 
> wrote:
> And we may still see the web stack being the ultimate cause of the delay.
> 
> 
> Parkinson's law always comes to the rescue:-)
> More faster and efficient processing architecture, Hyper transport buses, 
> amd-64 Branch prediction.
> Massively faster storage subsystems and disk arrays, SSD slab caching for 
> hypervisors
> 
> And some dude with a AJAX framework to serve a PDF bringging the whole 
> thing to a a screeching halt
> 
>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
>>> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
>>> Things will probably be easier this time. The Internet has evolved
>> ways
>>> of dealing with exactly this problem. (Avi used to call it “slash-dot
>> 
>>> insurance”, but the idea is the same.) Specifically:
>> 
>> Yep, it will be interesting to see where the chokepoints are tommorrow.
>> 
>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>> 
>> TCP and Web stacks. Eventually the Associated Press got a copy of the
>> Starr Report on a CD from a congressional staffer. The press intern
>> running down the street holding a CD was faster than 1998 internet :-)
>> 
>> We were also lucky in 1998, no one had thought of DDOS yet.
> 
> Frederick Wessling (CIO)
> Succinct Systems LLC
> Cell: +1(561) 571-2799
> Office: +1(904) 758-9915 ext. 9925
> Fax: +1(904) 758-9987
> www.SuccinctSystems.com
> 

Re: Special Counsel Office report web site

[Brett Watson]

Or maybe do this (faster than nanog archives) :) 


bash-3.2# dig cia.gov ns

; <<>> DiG 9.10.6 <<>> cia.gov ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cia.gov.   IN  NS

;; ANSWER SECTION:
cia.gov.86400   IN  NS  a22-66.akam.net.
cia.gov.86400   IN  NS  a16-67.akam.net.
cia.gov.86400   IN  NS  a1-22.akam.net.
cia.gov.86400   IN  NS  a12-65.akam.net.
cia.gov.86400   IN  NS  a3-64.akam.net.
cia.gov.86400   IN  NS  a13-65.akam.net.



> On Apr 17, 2019, at 9:11 PM, Martin Hannigan  wrote:
> 
> 
> Check the nANOG archives for examples of whitehouse.gov 
> , cia.gov  etc. It certainly is. 
> 
> 
> 
> On Wed, Apr 17, 2019 at 23:34  > wrote:
> Isn’t this why god invented CDNs? Though, i doubt the govment is Akamized...
> 
> -Mike
> 
> On Apr 17, 2019, at 20:26, Mark Seiden  > wrote:
> 
>> of course p2p is the way to distribute this but i doubt the justice 
>> department can admit there is any positive legitimate use for p2p.
>> 
>> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet.  
>> “russiar, are you listening?”)
>> 
>> (i sure hope there’s a signed version or at least a hash.)
>> 
>> i predict there will be versions with fake content, missing content, and 
>> malware inserted that are distributed as well.
>> 
>> 
>> 
>> 
>> and i’ll bet there will be some infected pdf version as well distributed 
>> that way.
>> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG > >, wrote:
>>> And we may still see the web stack being the ultimate cause of the delay.
>>> 
>>> 
>>> Parkinson's law always comes to the rescue:-)
>>> More faster and efficient processing architecture, Hyper transport buses, 
>>> amd-64 Branch prediction.
>>> Massively faster storage subsystems and disk arrays, SSD slab caching for 
>>> hypervisors
>>> 
>>> And some dude with a AJAX framework to serve a PDF bringging the whole 
>>> thing to a a screeching halt
>>> 
>>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan >> > wrote:
 On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
> Things will probably be easier this time. The Internet has evolved
 ways
> of dealing with exactly this problem. (Avi used to call it “slash-dot
 
> insurance”, but the idea is the same.) Specifically:
 
 Yep, it will be interesting to see where the chokepoints are tommorrow.
 
 In 1998, the bandwidth pipes never filled up. The chokepoint was in the
 
 TCP and Web stacks. Eventually the Associated Press got a copy of the
 Starr Report on a CD from a congressional staffer. The press intern
 running down the street holding a CD was faster than 1998 internet :-)
 
 We were also lucky in 1998, no one had thought of DDOS yet.
>>> 
>>> Frederick Wessling (CIO)
>>> Succinct Systems LLC
>>> Cell: +1(561) 571-2799
>>> Office: +1(904) 758-9915 ext. 9925
>>> Fax: +1(904) 758-9987
>>> www.SuccinctSystems.com 

Re: Special Counsel Office report web site

[Martin Hannigan]

Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It
certainly is.



On Wed, Apr 17, 2019 at 23:34  wrote:

> Isn’t this why god invented CDNs? Though, i doubt the govment is
> Akamized...
>
> -Mike
>
> On Apr 17, 2019, at 20:26, Mark Seiden  wrote:
>
> of course p2p is the way to distribute this but i doubt the justice
> department can admit there is any positive legitimate use for p2p.
>
> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent
> yet.  “russiar, are you listening?”)
>
> (i sure hope there’s a signed version or at least a hash.)
>
> i predict there will be versions with fake content, missing content, and
> malware inserted that are distributed as well.
>
>
>
>
> and i’ll bet there will be some infected pdf version as well distributed
> that way.
> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG ,
> wrote:
>
> And we may still see the web stack being the ultimate cause of the delay.
>
>
> Parkinson's law always comes to the rescue:-)
> More faster and efficient processing architecture, Hyper transport buses,
> amd-64 Branch prediction.
> Massively faster storage subsystems and disk arrays, SSD slab caching for
> hypervisors
>
> And some dude with a AJAX framework to serve a PDF bringging the whole
> thing to a a screeching halt
>
> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
>
> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
>
> Things will probably be easier this time. The Internet has evolved
>
> ways
>
> of dealing with exactly this problem. (Avi used to call it “slash-dot
>
>
> insurance”, but the idea is the same.) Specifically:
>
>
> Yep, it will be interesting to see where the chokepoints are tommorrow.
>
> In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>
> TCP and Web stacks. Eventually the Associated Press got a copy of the
> Starr Report on a CD from a congressional staffer. The press intern
> running down the street holding a CD was faster than 1998 internet :-)
>
> We were also lucky in 1998, no one had thought of DDOS yet.
>
>
> Frederick Wessling (CIO)
> Succinct Systems LLC
> Cell: +1(561) 571-2799
> Office: +1(904) 758-9915 ext. 9925
> Fax: +1(904) 758-9987
> www.SuccinctSystems.com
>
>

Re: Special Counsel Office report web site

[mike . lyon]

Isn’t this why god invented CDNs? Though, i doubt the govment is Akamized...

-Mike

> On Apr 17, 2019, at 20:26, Mark Seiden  wrote:
> 
> of course p2p is the way to distribute this but i doubt the justice 
> department can admit there is any positive legitimate use for p2p.
> 
> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet.  
> “russiar, are you listening?”)
> 
> (i sure hope there’s a signed version or at least a hash.)
> 
> i predict there will be versions with fake content, missing content, and 
> malware inserted that are distributed as well.
> 
> 
> 
> 
> and i’ll bet there will be some infected pdf version as well distributed that 
> way.
>> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , 
>> wrote:
>> And we may still see the web stack being the ultimate cause of the delay.
>> 
>> 
>> Parkinson's law always comes to the rescue:-)
>> More faster and efficient processing architecture, Hyper transport buses, 
>> amd-64 Branch prediction.
>> Massively faster storage subsystems and disk arrays, SSD slab caching for 
>> hypervisors
>> 
>> And some dude with a AJAX framework to serve a PDF bringging the whole thing 
>> to a a screeching halt
>> 
>>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
 On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
 Things will probably be easier this time. The Internet has evolved
>>> ways
 of dealing with exactly this problem. (Avi used to call it “slash-dot
>>> 
 insurance”, but the idea is the same.) Specifically:
>>> 
>>> Yep, it will be interesting to see where the chokepoints are tommorrow.
>>> 
>>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>>> 
>>> TCP and Web stacks. Eventually the Associated Press got a copy of the
>>> Starr Report on a CD from a congressional staffer. The press intern
>>> running down the street holding a CD was faster than 1998 internet :-)
>>> 
>>> We were also lucky in 1998, no one had thought of DDOS yet.
>> 
>> Frederick Wessling (CIO)
>> Succinct Systems LLC
>> Cell: +1(561) 571-2799
>> Office: +1(904) 758-9915 ext. 9925
>> Fax: +1(904) 758-9987
>> www.SuccinctSystems.com

Re: Special Counsel Office report web site

[Mark Seiden]

of course p2p is the way to distribute this but i doubt the justice department 
can admit there is any positive legitimate use for p2p.

(i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet.  
“russiar, are you listening?”)

(i sure hope there’s a signed version or at least a hash.)

i predict there will be versions with fake content, missing content, and 
malware inserted that are distributed as well.




and i’ll bet there will be some infected pdf version as well distributed that 
way.
On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , wrote:
> And we may still see the web stack being the ultimate cause of the delay.
>
>
> Parkinson's law always comes to the rescue:-)
> More faster and efficient processing architecture, Hyper transport buses, 
> amd-64 Branch prediction.
> Massively faster storage subsystems and disk arrays, SSD slab caching for 
> hypervisors
>
> And some dude with a AJAX framework to serve a PDF bringging the whole thing 
> to a a screeching halt
>
> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
> > On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
> > > Things will probably be easier this time. The Internet has evolved
> > ways
> > > of dealing with exactly this problem. (Avi used to call it “slash-dot
> >
> > > insurance”, but the idea is the same.) Specifically:
> >
> > Yep, it will be interesting to see where the chokepoints are tommorrow.
> >
> > In 1998, the bandwidth pipes never filled up. The chokepoint was in the
> >
> > TCP and Web stacks. Eventually the Associated Press got a copy of the
> > Starr Report on a CD from a congressional staffer. The press intern
> > running down the street holding a CD was faster than 1998 internet :-)
> >
> > We were also lucky in 1998, no one had thought of DDOS yet.
>
> Frederick Wessling (CIO)
> Succinct Systems LLC
> Cell: +1(561) 571-2799
> Office: +1(904) 758-9915 ext. 9925
> Fax: +1(904) 758-9987
> www.SuccinctSystems.com

Re: Special Counsel Office report web site

[fwessling--- via NANOG]

And we may still see the web stack being the ultimate cause of the delay.


Parkinson's law always comes to the rescue:-)
More faster and efficient processing architecture, Hyper transport buses, 
amd-64 Branch prediction.
Massively faster storage subsystems and disk arrays, SSD slab caching for 
hypervisors

And some dude with a AJAX framework to serve a PDF bringging the whole thing to 
a a screeching halt

On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
>On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
>> Things will probably be easier this time. The Internet has evolved
>ways 
>> of dealing with exactly this problem. (Avi used to call it “slash-dot
>
>> insurance”, but the idea is the same.) Specifically:
>
>Yep, it will be interesting to see where the chokepoints are tommorrow.
>
>In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>
>TCP and Web stacks. Eventually the Associated Press got a copy of the 
>Starr Report on a CD from a congressional staffer. The press intern 
>running down the street holding a CD was faster than 1998 internet :-)
>
>We were also lucky in 1998, no one had thought of DDOS yet.

Frederick Wessling (CIO)
Succinct Systems LLC
Cell: +1(561) 571-2799
Office: +1(904) 758-9915 ext. 9925
Fax: +1(904) 758-9987
www.SuccinctSystems.com

Re: Special Counsel Office report web site

[Sean Donelan]

On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
Things will probably be easier this time. The Internet has evolved ways 
of dealing with exactly this problem. (Avi used to call it “slash-dot 
insurance”, but the idea is the same.) Specifically:


Yep, it will be interesting to see where the chokepoints are tommorrow.

In 1998, the bandwidth pipes never filled up. The chokepoint was in the 
TCP and Web stacks. Eventually the Associated Press got a copy of the 
Starr Report on a CD from a congressional staffer. The press intern 
running down the street holding a CD was faster than 1998 internet :-)


We were also lucky in 1998, no one had thought of DDOS yet.

Re: Special Counsel Office report web site

[Patrick W. Gilmore]

On Apr 17, 2019, at 9:02 PM, Sean Donelan  wrote:
> 
> The Special Counsel's report is expected to be posted on its website sometime 
> between 11 a.m. and noon on Thursday, April 18, 2019.
> 
> https://www.justice.gov/sco
> 
> Since I helped with website for the Starr Report on September 11, 1998, I 
> wish all website admins and network admins well tommorrow morning.
> 
> # config t
> ip go faster

Sean:

I remember “ip go faster” when you first posted it back in 1998. It was 
hilarious, I literally “LOL”ed. However, I did not envy you your job with that 
short notice. (But I did envy you all the people who were willing to help on 
such short notice.) I am still impressed at what you were able to pull together 
in just a few days. Major Kudos.

Things will probably be easier this time. The Internet has evolved ways of 
dealing with exactly this problem. (Avi used to call it “slash-dot insurance”, 
but the idea is the same.) Specifically:

TiggerBook-C-32:~ patrick$ dig +short www.justice.gov
www.justice.gov.edgekey.net.
e7598.dscg.akamaiedge.net.

’Nuff said.

-- 
TTFN,
patrick

Special Counsel Office report web site

[Sean Donelan]

The Special Counsel's report is expected to be posted on its website 
sometime between 11 a.m. and noon on Thursday, April 18, 2019.


https://www.justice.gov/sco

Since I helped with website for the Starr Report on September 11, 1998, I 
wish all website admins and network admins well tommorrow morning.


# config t
ip go faster

Anyone from Home Town Communications in Florida that can contact me off list?

[Joseph Jenkins]

Need some help tracking down a device.

Thank you,

Joe

Re: Sflow billing or usage calculation software

[Peter Phaal]

On Tue, Apr 16, 2019 at 8:35 PM Deepak Jain  wrote:

> Now I know I'm pushing my luck... but do certain vendors more fully
> embrace sFlow than others? maybe one of the whitebox vendors if not one
> of the majors?
>
> Hacking support into something isn't the worse thing in the world, but
> if there is any experience on this to leverage off of, that is helpful.
>

Unfortunately, there isn't a publicly available list showing how well or
completely vendors have implemented the sFlow specifications:
https://sflow.org/developers/specifications.php

I have been working on an sFlow test suite to try and address this problem:
https://blog.sflow.com/2015/11/sflow-test.html

The source code for the tests is on GitHub:
https://github.com/sflow-rt/sflow-test

The easiest way to run the software is using Docker:
https://hub.docker.com/r/sflow/sflow-test

The goal is to compile a list of equipment and network operating systems
that pass the tests and publish the results on sFlow.org. Failed tests can
be passed to vendors to help them improve their implementations. In
addition to identifying feature support, there are also stress tests to
ensure accurate results under production workloads (rapid detection of DDoS
etc).

Involvement of operators would be great. If there are tests that are
missing from the suite, please submit an enhancement request, or even
better, a pull request, on GitHub. If you have a test lab and can run the
tests on your own hardware, please share the results.

The open source Host sFlow agent, https://sflow.net/, has been ported to a
number of white box network operating systems and provides an opportunity
for the community to extend sFlow functionality and address issues in the
white box ecosystem. Operator involvement in this project would be most
welcome.

Peter