There’s been no comment on this announcement on this list, but there were a
small handful of NANOGers who energetically discussed this on the arin-consult
list starting mid-August.
On the last day of the comment period (so you might have missed it), a detailed
comment was submitted, which focus
On Thu, Sep 03, 2015 at 07:57:55PM +, Marcin Cieslak wrote:
> whois.net is some site operated by NTT/Verio,
> this domain tech contact seems to be:
>
> Tech Name: Verio Hostmaster
> Tech Organization:
> Tech Street: 8005 S. Chester Street Suite 200
> Tech City: Englewood
> Tech State/Province
On Thu, 3 Sep 2015, Brian Reichert wrote:
> On Thu, Sep 03, 2015 at 09:59:02PM +0700, David S. wrote:
> > Hi Brian,
> >
> > I'm able to access https://whois.net, have you check the nameserver of
> > numachi.com?
> > Is the other domain use same authoritative DNS?
>
> I can access the web page.
On Thu, Sep 03, 2015 at 09:59:02PM +0700, David S. wrote:
> Hi Brian,
>
> I'm able to access https://whois.net, have you check the nameserver of
> numachi.com?
> Is the other domain use same authoritative DNS?
I can access the web page. When I use the page for certain domains,
sometimes, I succe
On Thu, Sep 03, 2015 at 05:48:00PM +0300, Saku Ytti wrote:
> Hey Brett,
>
> > Here's a paper that shows you don't need buffers equal to
> > bandwidth*delay to get near capacity:
> > http://www.cs.bu.edu/~matta/Papers/hstcp-globecom04.pdf
> > (I'm not endorsing it. Just pointing out it out as a dat
I'm trying to use https://www.whois.net/ to resolve info about
several domains, including my own (NUMACHI.COM).
For several domains (but not all, I get 'Error extracting data. No
data available'. There's a 'please read' tag, but no text associated
with it.
Anyone know if they're having issues th
Hey Brett,
> Here's a paper that shows you don't need buffers equal to
> bandwidth*delay to get near capacity:
> http://www.cs.bu.edu/~matta/Papers/hstcp-globecom04.pdf
> (I'm not endorsing it. Just pointing out it out as a datapoint.)
Quick glance makes me believe the S and D nodes are equal ba
On Thu, Sep 03, 2015 at 01:04:34PM +0100, Nick Hilliard wrote:
> On 03/09/2015 11:56, Saku Ytti wrote:
> > 40GE server will flood the window as fast as it can, instead of
> > limiting itself to 10Gbps, optimally it'll send at linerate.
>
> optimally, but tcp slow start will generally stop this fro
That would do it. Almost certainly enforced by GPO in that case so at least
it's easy to change if you need to.
On Thu, Sep 3, 2015 at 10:25 AM, Robert Webb wrote:
> Yes, we are looking at this now.
>
> Thanks for everyone's help. I think we are heading in the right direction
> tracking this dow
Yes, we are looking at this now.
Thanks for everyone's help. I think we are heading in the right direction
tracking this down. This just showed up in our monitoring and makes sense as
we just brought up a new locked down domain.
Robert
On Thu, 3 Sep 2015 10:19:53 -0400
"Oliver O'Boyle" wr
Precisely.
On Thu, Sep 3, 2015 at 10:14 AM, Chuck Anderson wrote:
> Sounds like Opportunistic Encryption.
>
> https://en.wikipedia.org/wiki/Opportunistic_encryption#Windows_OS
>
> On Thu, Sep 03, 2015 at 09:53:46AM -0400, Robert Webb wrote:
> > There is no VPN in the picture here. These are stra
You can configure Windows to encrypt traffic based on protocol definitions.
E.g., Use IPSEC to encrypt all traffic on port 80 between hosts X and hosts
Y.
It's possible that such a policy is in place locally on the workstations
and/or servers and it's also possible that it's being enforced using G
Sounds like Opportunistic Encryption.
https://en.wikipedia.org/wiki/Opportunistic_encryption#Windows_OS
On Thu, Sep 03, 2015 at 09:53:46AM -0400, Robert Webb wrote:
> There is no VPN in the picture here. These are straight workstations
> on the network that the packets are coming from.
>
> Accor
There is no VPN in the picture here. These are straight workstations on the
network that the packets are coming from.
According to a pcaket capture in wireshark, these are isakmp packets
reaching out to host names of web sites that are being browsed. So
destinations are sites like twitter, fac
> On 03 Sep 2015, at 13:35 , Robert Webb wrote:
>
> We are seeing udp 500 packets being dropped at our firewall from user's
> browsing sessions. These are users on a 2008 R2 AD setup with Windows 7.
>
> Source and destination ports are udp 500 and the the pattern of drops
> directly correlate
We are seeing udp 500 packets being dropped at our firewall from user's
browsing sessions. These are users on a 2008 R2 AD setup with Windows 7.
Source and destination ports are udp 500 and the the pattern of drops
directly correlate to the web browsing activity. We have confirmed this with
tc
On 3 September 2015 at 15:04, Nick Hilliard wrote:
> optimally, but tcp slow start will generally stop this from happening on
> well behaved sending-side stacks so you send up ramping up quickly to path
> rate rather than egress line rate from the sender side.
This assumes network is congested a
On 03/09/2015 11:56, Saku Ytti wrote:
> 40GE server will flood the window as fast as it can, instead of
> limiting itself to 10Gbps, optimally it'll send at linerate.
optimally, but tcp slow start will generally stop this from happening on
well behaved sending-side stacks so you send up ramping up
> only serialise them 10GE out, causing majority of that 375MB ending up
> in the sender side switch/router buffers.
s/sender/receiver/
--
++ytti
Hey,
In past few years there's been lot of talk about reducing buffer
depths, and many seem to think vendors are throwing memory on the
chips for the fun of it.
If we look at some particularly pathological case. Let's assume sender
is CDN network with 40GE connected server and receiver is 10GE
co
20 matches
Mail list logo
