- Test - lists.nanog.org

Re: TCP congestion control and large router buffers
by Mikael Abrahamsson 14 Dec '10

14 Dec '10

On Tue, 14 Dec 2010, Sam Stickland wrote: > But there's no need for AQM, just smaller buffers would make a huge > difference. Well, yes, buffering packets more than let's say 30-50ms on a 1 meg link doesn't make much sense. But doing some basic AQM would make things even better (some packets would see 0 buffering instead of 30ms). > Surely buffers that can store seconds worth of data are simply too big? FIFO with seconds worth of data is just silly, yes. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

2 2

peering, derivatives, and big brother
by Jeff Wheeler 14 Dec '10

14 Dec '10

A read through this New York Times article on derivatives clearing, and the exclusivity that big banks seek to maintain, would look very much like an article on large-scale peering, to someone who is not expert in both topics. The transit-free club and the "derivatives dealers club" may have other similarities in the future, and it's worth watching how further government regulation develops in this area. It may lead to insight into how government might eventually regulate ISPs seeking to become settlement-free. "“It appears that the membership criteria were set so that a certain group of market participants could meet that, and everyone else would have to jump through hoops,” Mr. Katz said." http://www.nytimes.com/2010/12/12/business/12advantage.html?pagewanted=1&_r… -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

7 9

Re: TCP congestion control and large router buffers
by Mikael Abrahamsson 14 Dec '10

14 Dec '10

On Mon, 13 Dec 2010, Sam Stickland wrote: > Ironically though, wouldn't smaller buffers cost less thus making the CPEs 1 megabyte of buffer (regular RAM) isn't really expensive. > cheaper still? I believe the argument made in the blog post is that > cheaper RAM been causing the CPE manufacturers to mistakenly provision > too much buffer space, which in turn apparently means that TCP can't > stabilize at a rate less than available bandwidth (I.e. It's the old > 1980's congestion collapse problem all over again). Of course, you'll > only see this if a single TCP stream is actually capable of saturating > the link. Sam I would guess they're running standard OSes and haven't tuned the buffers at all. Implementing WRED or fair-queue (even if it just means turning it on) requires validation which the CPE manufacturers want to minimize. Also it's our fault as a business, how many ISPs have included AQM in their RFPs for CPEs and actually would pay USD5 more per device for this feature? I'm not very surprised at the lack of this though, it's hard to explain to the end customer with some kind of marketing, both for the ISP and the CPE vendor if they're selling to end customers. It's one of those "in the black box" things that should just work, but there is little upside in having it because it's hard to charge for. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 0

(no subject)
by Atticus 13 Dec '10

13 Dec '10

Cc

5 4

Re: Wake on LAN in the enterprise
by Berry Mobley 13 Dec '10

13 Dec '10

Thanks, everyone, for the replies - looks like I need to get my server team interested in knowing broadcast addresses for hosts, and making SMS send to those addresses. I do have the 'ip directed-broadcast <acl>' in place, but the servers are currently sending the magic packets to the all-1's address. Maybe I can get that changed. Berry

1 0

That thing the USG keeps sending people to OECD meetings to try to obfuscate:
by Bill Woodcock 13 Dec '10

13 Dec '10

http://tech.slashdot.org/submission/1416250/68-of-US-broadband-connections-… -Bill

1 0

Re: Wake on LAN in the enterprise
by Daniel Hagerty 13 Dec '10

13 Dec '10

Owen DeLong <owen(a)delong.com> writes: > WOL is unfortunately terribly deficient in that the spec. never = > envisioned the possibility > of a need for wake on WAN. > > Bottom line, it's a non-routeable layer 2 protocol. Your choices boil = > down to the > helper address nightmare you describe or proxy servers on every subnet. WoL works just fine over routed networks; the magic packet format doesn't preclude it. I send WoL over routed networks several times a day. The only gotcha is that you need some kind of arrangement for either directed broadcast, or hardcode ndp/arp entries. Perl code snippet below: my $wolhost = "wolhost.example.com"; my $wolhost_mac = "de:ad:be:ef:ca:fe"; my $mac = $wolhost_mac; $mac =~ s/[: ]//g; # Use socat to build a wakeonlan packet inside a udp6 datagram. my $packed_bcast = pack("H12", "f" x 12); my $packed_mac = pack("H12", $mac); my $dgram = $packed_bcast . ( $packed_mac x 16); # 9 is the discard port. For whatever reason, the wrong thing # happens when the port is referenced by name, despite having the # name in /etc/services. open(SOCAT, "|-", (qw(socat -u STDIN), "UDP6-DATAGRAM:$wolhost:9")) || die "popen: $!"; print SOCAT $dgram || die "print: $!"; close(SOCAT);

1 0

Re: Wake on LAN in the enterprise
by Atticus 13 Dec '10

13 Dec '10

Appologies to all that got a quote email from me. My phone decided to pocket-reply to you.

1 0

Re: Wake on LAN in the enterprise
by Jack Bates 13 Dec '10

13 Dec '10

On 12/13/2010 10:43 AM, Christopher.Marget(a)usc-bt.com wrote: > Jack Bates: >> I would suspect that proxy servers being the better deal, though >> my experience with Cisco is that you may have to use ASR type gear >> to get a nicer layout (similar to service providers) where you can >> backend everything to a radius server (I'm still waiting to test >> this myself, but IOS is really weak on DHCP support). > > I hope someone will please clarify the problem statement? > My problem is lack of WOL experience and associating dhcp-helper address with DHCP; ie, speaking without knowledge. I'm bad about that. :) > The only router/switch configuration required was to permit directed > broadcasts from the systems doing the waking. On by default, I > believe, but locked down in my environment. > IOS specific, I believe. Some have it on; some have it off. Jack

1 0

Re: Wake on LAN in the enterprise
by Patrick Giagnocavo 13 Dec '10

13 Dec '10

On 12/13/2010 11:08 AM, Berry Mobley wrote: > Hello... > > I'm trying to get a handle on implementation of wake-on-lan in an > enterprise environment. Cisco gear, lots of subnets. I've made it work > with directed broadcasts, but I'd really rather not have 40 or 50 'ip > helper-address x.x.x.bcastaddr' statements on the vlans with the SMS > servers. > Assuming you are talking servers and not desktops, you will probably end up doing this with IPMI, which most servers have on-motherboard these days. Cordially Patrick

1 0