Re: Big Temporary Networks
just a small comment: As far as I understand AP isolation doesn't work if you don't have a WLAN controller but do have more than one APs. E.g. in the following setup ap1--sw1--sw2--ap2 with AP isolation turned on, clients associated to ap1 cannot communicate directly with other clients associated to ap1, however they can communicate directly with those associated to ap2. Broadcast from ap1's clients does also get to all clients at ap2. Hi András, This is one place where Cisco's switchport protected comes in handy. Yes, but only as long as all APs are connected to the same switch, as I understand. (That's why I put two switches in the example above.) You can get the same effect with other brands. For example, in one on-the-cheap 5-AP hotspot I did, I vlaned the APs (using an older 802.1q capable switch) back to a Linux bridge with ebtables --insert FORWARD --jump DROP. The Linux bridge was also the default router out of the wlan, so anything *to* the router worked but anything that would be forwarded was dropped instead. Works great. Nice, that should do the trick with multiple switches too. Regards, András
Re: Big Temporary Networks
Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the AP isolation feature that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. Not related to the original subject, neither to IPv6 usability on WLANs, just a small comment: As far as I understand AP isolation doesn't work if you don't have a WLAN controller but do have more than one APs. E.g. in the following setup ap1--sw1--sw2--ap2 with AP isolation turned on, clients associated to ap1 cannot communicate directly with other clients associated to ap1, however they can communicate directly with those associated to ap2. Broadcast from ap1's clients does also get to all clients at ap2. Regards, András
Re: Big Temporary Networks
On Sun, Sep 23, 2012 at 3:50 PM, JÁKÓ András jako.and...@eik.bme.hu wrote: Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the AP isolation feature that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. Not related to the original subject, neither to IPv6 usability on WLANs, just a small comment: As far as I understand AP isolation doesn't work if you don't have a WLAN controller but do have more than one APs. E.g. in the following setup ap1--sw1--sw2--ap2 with AP isolation turned on, clients associated to ap1 cannot communicate directly with other clients associated to ap1, however they can communicate directly with those associated to ap2. Broadcast from ap1's clients does also get to all clients at ap2. Hi András, This is one place where Cisco's switchport protected comes in handy. Plug both APs into switches where the port is set to protected mode and neither they nor the associated clients will be able to talk to each other. You can get the same effect with other brands. For example, in one on-the-cheap 5-AP hotspot I did, I vlaned the APs (using an older 802.1q capable switch) back to a Linux bridge with ebtables --insert FORWARD --jump DROP. The Linux bridge was also the default router out of the wlan, so anything *to* the router worked but anything that would be forwarded was dropped instead. Works great. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
On Fri, Sep 21, 2012 at 10:42 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: William Herrin wrote: that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. The DAD packets are simply never sent to the other stations. You are saying to disable DAD, which is a violation of SLAAC. We do that on some wired ethernets too. The Cisco configuration command is switchport protected. It helps control virus outbreaks if machines designated clients can't talk to each other at layer 2, regardless of how that annoys layer 3. Does this bother you? Tough. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
William Herrin wrote: You are saying to disable DAD, which is a violation of SLAAC. We do that on some wired ethernets too. You are calling such a link Ethernet. OK. Fine. The Cisco configuration command is switchport protected. It helps control virus outbreaks if machines designated clients can't talk to each other at layer 2, regardless of how that annoys layer 3. It means IPv6 is broken over not only WiFi but also Ethernet. Does this bother you? No, not me, not at all. Masataka Ohta
Re: Big Temporary Networks
On Thu, Sep 20, 2012 at 11:54 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Tony Hain wrote: where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. You miss multicast storm caused by DAD. This is a long solved issue. First, it already occurs with ARP broadcasts which the AP in principle resends out to everybody else on the wlan. Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the AP isolation feature that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. The DAD packets are simply never sent to the other stations. In theory there are some problems with this. In practice, it's in wide deployment and has been demonstrated to work just fine. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
William Herrin wrote: You miss multicast storm caused by DAD. Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the AP isolation feature As you stated : I think Masataka meant to say (and said previously) that the DHCP : request from the wifi station is, like all packets from the wifi : station to the AP, subject to wifi's layer 2 error recovery. that is not a problem for IPv4 ARP and DHCP. that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. The DAD packets are simply never sent to the other stations. You are saying to disable DAD, which is a violation of SLAAC. In theory there are some problems with this. In practice, it's in wide deployment and has been demonstrated to work just fine. Tell it to IETF to modify SLAAC to exclude DAD. Masataka Ohta
Re: Big Temporary Networks
David Miller wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Masataka Ohta
Re: Big Temporary Networks
On Thu, Sep 20, 2012 at 2:21 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: David Miller wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Heavy reliance on broadcast for a wide range of instances where the traffic is really only destined for a single node would seem to be rather sub-optimal. /TJ
Re: Big Temporary Networks
- Original Message - From: William Herrin b...@herrin.us My point is that blaming union contracts or union anything for being unable to find a place to hold a convention where you can implement the network you want to implement is nonsense. NANOG, ARIN and IETF conferences have all somehow managed to implement their own effective networks. Even in union towns. If Worldcon's site selection committee can't find a suitable host, that's their deficiency. That's as may be, Bill, but it is definitively outside *my* personal scope, here. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
- Original Message - From: Rick Alfvin ralf...@verilan.com Verilan is the exclusive network services provider for NANOG, IEEE 802, IETF, ICANN, ZigBee Alliance, MAAWG, OIF, GENIVI, Tizen and many other technical organizations. We deploy large temporary networks to provide high density WI-Fi for meetings, events and conferences all over the world where Internet connectivity is mission critical to the success of the event. I'm quite certain I have a good idea of the magnitude of what you'd charge for professional services for such work, and I would expect it to be 2-3 orders of magnitude larger than what a Worldcon Concom could afford to pay. :-) I would also be very surprised -- having been on NANOG for over a decade now and never having heard your name -- to find out that you were the Exclusive Network Services Provider for NANOG... And I expect they'd be surprised too. Hey! Let's ask them! :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
On 9/20/12 9:52 AM, Jay Ashworth wrote: I'm quite certain I have a good idea of the magnitude of what you'd charge for professional services for such work, and I would expect it to be 2-3 orders of magnitude larger than what a Worldcon Concom could afford to pay. :-) I would also be very surprised -- having been on NANOG for over a decade now and never having heard your name -- to find out that you were the Exclusive Network Services Provider for NANOG... And I expect they'd be surprised too. Hey! Let's ask them! :-) Cheers, -- jra That's funny, my mailing archive says you had a conversation with the network contractor on this list during NANOG 53.
RE: Big Temporary Networks
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Wednesday, September 19, 2012 11:21 PM To: David Miller Cc: nanog@nanog.org Subject: Re: Big Temporary Networks David Miller wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Your own example --- -Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Wednesday, September 19, 2012 1:26 AM To: nanog@nanog.org Subject: Re: Big Temporary Networks ... that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs ... IPv4 has a train load of devices unicasting and retransmitting all the dropped packets, where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. Therefore IPv4 is suboptimal in its abuse of the air link which could have been used for real application traffic instead of being wasted on device configuration. Thus by extension using your logic it is not operational. Just because you personally want IPv6 to be nothing more than IPv4 in every aspect is no reason to troll the nanog list and create confusion that causes others to delay their IPv6 deployment. Your complaints about IPv6 behavior on wifi ignore the point that IPv6 ND behavior was defined before or in parallel as wifi was defined by a different committee. There will always be newer L2 technologies that arrive after an L3 protocol is defined, and the behavior of the L3 will be 'suboptimal' for the new L2. When the issue is serious enough to warrant documentation, addendum documents are issued. When it is simply a matter of personal preference, it is hard to get enough support to get those documents published. Tony
Re: Big Temporary Networks
TJ wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Heavy reliance on broadcast for a wide range of instances where the traffic is really only destined for a single node would seem to be rather sub-optimal. It's not sub-optimal w.r.t. link bandwidth, if the link is a broadcast domain. Moreover, broadcast is no worse than all-node multicast. And, given the CATENET model of the Internet to connect broadcast domains including small number of devices by routers, over which there is no broadcast, that is a sub-optimal operation. In this thread, there is an example of such an operation to have a lot of WiFi base stations with omnidirectional antennas at full power. No protocol can be fool proof against sub-optimal operations. Masataka Ohta
Re: Big Temporary Networks
Tony Hain wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Your own example --- ... that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs ... IPv4 has a train load of devices unicasting and retransmitting all the dropped packets, IPv4 merely need a broadcast ARP request and broadcast DHCP discover to be piggy backed in a single IEEE802.11ai frame reliably unicast to an AP. where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. You miss multicast storm caused by DAD. Just because you personally want IPv6 to be nothing more than IPv4 in every aspect is no reason to troll the nanog list and create confusion that causes others to delay their IPv6 deployment. Just because IPv6 is working without much problem somehow somewhere is not a valid reason to say others should use IPv6. As IP is so essential to the Internet, IP protocol must be perfect w.r.t. the scale and diversity of the Internet. IPv4 has evolved so, as the Internet evolve. IPv6 could have been so, if it were a exact copy of IPv4 save address length. But, it is not, which is why IPv6 failed on various points which are different from IPv4. Your complaints about IPv6 behavior on wifi ignore the point that IPv6 ND behavior was defined before or in parallel as wifi was defined by a different committee. The problem is ND uber Alles approach, which makes it impossible to make IP uber Alles. There will always be newer L2 technologies that arrive after an L3 protocol is defined, and the behavior of the L3 will be 'suboptimal' for the new L2. When the issue is serious enough to warrant documentation, addendum documents are issued. Because of ND uber Alles approach, the document just says IPv6 works suboptimal without solving the issue. OTOH with IPv4, the document can solve the problem by having a new adaptation mechanism much different from ARP or PPP. Masataka Ohta
Re: Big Temporary Networks
Op 18-9-2012 22:50, William Herrin schreef: On Tue, Sep 18, 2012 at 4:31 PM, Nick Hilliard n...@foobar.org wrote: On 18/09/2012 21:24, William Herrin wrote: IPv6 falls down compared to IPv4 on wifi networks when it responds to a router solicitation with a multicast (instead of unicast) router advertisement. You mean it has one extra potential failure mode in situations where radio retransmission doesn't deal with the packet loss - which will cause RA to retry. Fall down is a slight overstatement. Potayto, potahto. Like I said, I have no interest in defending IPv6. But I'm very interested in how to implement an IPv6 network that's as or more reliable than the equivalent IPv4 network. That makes me interested in the faults which get in the way. Regards, Bill Herrin Yes, radvd has a configuration option to send unicast packets. But I think the effects are slightly overstated. Unless someone fudged the lifetime counters on the ra config nobody will ever notice a RA getting lost. Once every few seconds a RA message will be sent and it will be valid for atleast a couple of minutes. Within that time there will be multiple RA announcements, and unless you missed 5 minutes of RA advertisements everything is fine. And if you do miss 5 minutes of RA multicast traffic, really, you have bigger problems. I see network stacks springing to life in the space of 3 seconds on the 1st message I send out. That's pretty stellar, and faster then some clients perform the DHCPv4 request. Also note that some wifi networks eat DHCPv4 broadcasts too, which is pretty much the same deal as what you are referring to above. They will retry the DHCPv4 request, and so do client that perform router sollicitation requests. No different. And if the wifi network is so bad that you have icmp and udp dropping like mad, I doubt anybody would want to use it. You are more likely that they will disable wifi altogether and use 3g. The 2.4Ghz wifi band is so crowded now that this has become the effective standard. Unless you are a happy camper that actually has a wifi card that supports the 5Ghz band. Which is far too uncommon in phones and tablets. boo. Cheers, Seth
Re: Big Temporary Networks
William Herrin wrote: Unicast since its responding to a solicitation? RFC4861 states: A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. Ah, okay. So the IPv6 router usually responds to router discovery with Don't ignore how is the implementations in the real world: : and a comment in rtadvd on the solicited advertisement: : : /* : * unicast advertisements : * XXX commented out. reason: though spec does not forbit it, unicast : * advert does not really help But correct me if I'm wrong: the router advertisement daemon could be altered to reply with unicast without changing the standard, right? See above. What do the radvd and rtadvd developers say about this when confronted with the 802.11 multicast problem? I reported the problem to IPv6 (or IPng?) WG more than 10 years ago (before rtadvd was developed) and Christian Huitema acknowledged that the problem does exist. Since then, nothing happened. Are there any Internet drafts active in the IETF to replace that MAY with a SHOULD, noting that replying with multicast can defeat layer 2 error recovery needed for the successful use of some layer 1 media? Didn't you say without changing the standard? What did I miss? Where does IPv6 take the bad turn that IPv4 avoided? You still miss DAD. DupAddrDetectTransmits should be 3, 5 or maybe 10 (depending on level of congestion), which means even more time is wasted. Worse, increasing DupAddrDetectTransmits increases level of congestion, which means congestion collapse occurs with use case senario of IEEE802.11ai. I have no interest in defending IPv6. We're network operators here. You just told us (and offered convincing reasoning) that when selecting a router vendor for use with an IPv6 wifi network, one of our evaluation check boxes should should be, Responds to ICMPv6 router solicitation with a unicast message? Yes or Fail. And when we provide the list of deficiencies to our vendor and wave the wad of cash around, one of them should be, Responds to ICMPv6 router solicitations with a multicast packet - unreliable in a wifi environment. That's strikes me as something valuable to know. Far more valuable than, Dood, IPv6 has problems on wifi networks. The only thing operators have to know about IPv6 is that IPv6, as is currently specified, is not operational. Then, let IETF bother. Masataka Ohta
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Tue, Sep 18, 2012 at 01:03:00PM -0700 Quoting Jo Rhett (jrh...@netconsonance.com): On Sep 13, 2012, at 7:29 AM, Jay Ashworth wrote: I'm talking to the people who will probably be, in 2015, running the first Worldcon I can practically drive to, in Orlando, at -- I think -- the Disney World Resort. I've told them how critical the issue is for this market; they, predictably, replied We look forward to your patch. :-} So I just want to point out that this is an utterly irrelevant topic. Worldcon is full to the brim with really smart people who can build good networks, but in every place large enough to host a Worldcon the owners of the building make money selling Internet access and don't want competition. The very best we've been able to do was create an Internet Lounge with good connectivity, and even that isn't acceptable at most locations. All the IETF and RIPE meetings I've been to have had excellent custom networks. How come? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 How do you explain Wayne Newton's POWER over millions? It's th' MOUSTACHE ... Have you ever noticed th' way it radiates SINCERITY, HONESTY WARMTH? It's a MOUSTACHE you want to take HOME and introduce to NANCY SINATRA! signature.asc Description: Digital signature
Re: Big Temporary Networks
Seth Mos wrote: Yes, radvd has a configuration option to send unicast packets. But I think the effects are slightly overstated. A senario considered by IEEE11ai is that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs. Then, it is essential to reduce the number of control packet exchanges. Also note that some wifi networks eat DHCPv4 broadcasts too, As I already stated, DHCP discover/request from STA to AP is unicast. And if the wifi network is so bad that you have icmp and udp dropping I'm afraid you don't understand CSMA/CA at all. Masataka Ohta
Re: Big Temporary Networks
SNIP The only thing operators have to know about IPv6 is that IPv6, as is currently specified, is not operational. I think it is safe to say that this is provably false. Are there opportunities for increased efficiency, perhaps ... however: I get native IPv6 at home via my standard residential cable connection using off the shelf CPE gear and standard OSes. I get native IPv6 via my standard LTE devices, again - off the shelf - no customization required. *(Repeated emphasis on the use of standard, off the shelf components here ... no end-user hacking/tweaking, nor custom firmware loads, nor special requests to the provider ... it just works.)* * * Both of these have been properly functioning since being lit up. Clearly, atleast the two *rather large* operators involved *(Comcast Verizon Wireless, if it matters) *have deployed IPv6 in an operational fashion. I bet Hurricane Electric would *strongly* disagree as well. *... Not to mention the enterprise networks and hosting facilities that have also implemented IPv6 rather successfully, all of which are relying on some carrier(s) to provide them connectivity.* /TJ
Re: Big Temporary Networks
On Sep 19, 2012, at 04:25, Masataka Ohta wrote: As I already stated, DHCP discover/request from STA to AP is unicast. This didn't sound right, so I decided to test. With the three clients available to me (laptop running OS X 10.7.4, phone running Android 4.0, and iPod running iOS 4.1.2) all client-server DHCP was broadcast, as well as server-client NACKs. Server-client offers and ACKs were unicast. --- Sean Harlow s...@seanharlow.info
Re: Big Temporary Networks
Sean Harlow wrote: As I already stated, DHCP discover/request from STA to AP is unicast. This didn't sound right, so I decided to test. Your test is invalid. With the three clients available to me (laptop running OS X 10.7.4, phone running Android 4.0, and iPod running iOS 4.1.2) all client-server DHCP was broadcast Of course. However, at WiFi L2, it is first unicast to AP and then broadcast by the AP. Masataka Ohta
Re: Big Temporary Networks
TJ wrote: The only thing operators have to know about IPv6 is that IPv6, as is currently specified, is not operational. I think it is safe to say that this is provably false. You failed to do so. Are there opportunities for increased efficiency, perhaps ... however: Congestion collapse is not a matter of mere efficiency. I get native IPv6 at home via my standard residential cable connection using off the shelf CPE gear and standard OSes. I get native IPv6 via my standard LTE devices, again - off the shelf - no customization required. That IPv6 works fine sometimes in some environment is not a valid proof that IPv6 is operational. Purposelessly bloated specification of IPv6 cause problems in some environment, against which removal of features is the only cure. It's like not using IP options, even though they are defined in RFC791. Masataka Ohta
Re: Big Temporary Networks
On Thu, 20 Sep 2012 06:54:35 +0900, Masataka Ohta said: Sean Harlow wrote: As I already stated, DHCP discover/request from STA to AP is unicast. This didn't sound right, so I decided to test. Your test is invalid. You forgot to include a .jpg of Darth Vader playing bagpipes on a unicycle or similar. http://knowyourmeme.com/memes/your-argument-is-invalid pgps3IrjsdBoW.pgp Description: PGP signature
Re: Big Temporary Networks
On Wed, Sep 19, 2012 at 11:33 AM, Sean Harlow s...@seanharlow.info wrote: On Sep 19, 2012, at 04:25, Masataka Ohta wrote: As I already stated, DHCP discover/request from STA to AP is unicast. This didn't sound right, so I decided to test. With the three clients available to me (laptop running OS X 10.7.4, phone running Android 4.0, and iPod running iOS 4.1.2) all client-server DHCP was broadcast, as well as server-client NACKs. Server-client offers and ACKs were unicast. I think Masataka meant to say (and said previously) that the DHCP request from the wifi station is, like all packets from the wifi station to the AP, subject to wifi's layer 2 error recovery. It's not unicast but its subject to error recovery anyway. In the return direction (AP to station) broadcast and multicast packets are not subject to error recovery while unicast packets are. Hence the the DHCPv4 server-client unicast offers and acks pass reliably while IPv6's equivalent multicast ICMPv6 router advertisements do not. On Wed, Sep 19, 2012 at 5:54 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: However, at WiFi L2, it is first unicast to AP and then broadcast by the AP. Your use of nomenclature is incorrect. It'd be like saying my ethernet card unicasts a packet to the switch and then the switch broadcasts it out all ports. Or like saying that a packet with an explicit MAC destination is a broadcast packet because the switch doesn't have the address in its MAC table. The packet is flooded out all ports but its not a broadcast packet. A layer 2 packet was unicast, multicast or broadcast moment I attached the appropriate destination MAC. The exact handling on a particular segment of the layer 2 network, while important in other contexts, is irrelevant to the designation unicast, multicast or broadcast. On Wed, Sep 19, 2012 at 3:26 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: The only thing operators have to know about IPv6 is that IPv6, as is currently specified, is not operational. No offense, but it is not for you or I or Owen Delong to declare that IPv6 is or isn't operational. Operators of individual networks can and will decide for themselves whether and when IPv6 is sufficiently operational for their use. Your observation about IPv6's equivalent of an ARP reply using multicast so that it misses wifi's layer 2 error recorvery (and thus performs poorly compared to IPv4) was of value. Got any more or are we ready to move on? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
William Herrin wrote: I think Masataka meant to say (and said previously) that the DHCP request from the wifi station is, like all packets from the wifi station to the AP, subject to wifi's layer 2 error recovery. It's not unicast but its subject to error recovery anyway. Mostly correct. But, as I already wrote: 1) broadcast/multicast from a STA attacked to an AP is actually unicast to the AP and reliably received by the AP (and relayed unreliably to other STAs). That is, a broadcast ARP request from the STA to the AP is reliably received by the AP. Because of hidden terminals, L2 broadcast/multicast is transmitted only from AP. However, at WiFi L2, it is first unicast to AP and then broadcast by the AP. Your use of nomenclature is incorrect. It'd be like saying my ethernet Ethernet? card unicasts a packet to the switch and then the switch broadcasts it out all ports. Or like saying that a packet with an explicit MAC destination Do you know MAC header of 802.11 contains four, not just source and destination, MAC addresses? Because of hidden terminals and because of impossibility of collision detection, WLAN is a little more complex than your guess. No offense, but it is not for you or I or Owen Delong to declare that IPv6 is or isn't operational. A single counter example is enough to deny IPv6 operational. whether and when IPv6 is sufficiently operational for their use. The scope is not their use but as a protocol for the entire Internet. Masataka Ohta
Re: Big Temporary Networks
On Wed, Sep 19, 2012 at 9:24 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: A single counter example is enough to deny IPv6 operational. Really? If that is really your opinion, the entire conversation is a rather moot point as I believe you and pretty much the rest of the world (again, including all those who helped develop and have deployed / are deploying IPv6) are not in agreement. *Not saying popularity equals correctness, just that there is a sizable counter-point to your statement. * Yes, the goal should be to minimize the special cases but there will always some of those. That is what the ~IPv6 over Foo series of documents is all about, accommodating those needs ... A single counter example is *only *enough to say that IPv6 does not *currently/ideally* fit *that* deployment scenario and that, just perhaps, *that deployment* needs some special consideration(s) on the part of IPv6. It does not, in any way, invalidate the protocol as a whole. Let me ask, in your opinion: Is the better and easier answer here to start from scratch, or to identify the problem(s) and simply fix it(them) if warranted? /TJ
Re: Big Temporary Networks
TJ wrote: A single counter example is enough to deny IPv6 operational. Really? With the Internet wide scope, yes, of course. In general, as IPv6 was designed to make ND uber Alles, not IP uber Alles, and ND was designed by a committee with only ATM, Ethernet and PPP in mind, ND can not be an adaptation mechanism to run IP over various link with link specific properties. Thus, even though people only using Ethernet and PPP might think ND is good enough, a single example of a link is enough to deny ND uber Alles. Though you wrote: I think it is safe to say that this is provably false. it is impossible because it is probatio diabolica. Instead, a single counter example is enough to totally deny probatio diabolica. Or, if you need another example on how poorly ND behaves under some environment, it's timing constraints are specified mostly in units of second, not millisecond, because the IPv6 committee silently assumed that hosts are immobile. Thus, latency imposed by ND is often too large for links with quickly moving objects. Never claim IPv6 operational with your narrowly scoped experiences, because what you are attempting to do is probatio diabolica. That is what the ~IPv6 over Foo series of documents is all about, accommodating those needs ... Because ND uber Alles is impossible, IPv6 over Foo series specifying ND parameters are not helpful. Masataka Ohta
Re: Big Temporary Networks
On 9/19/2012 11:33 PM, Masataka Ohta wrote: TJ wrote: A single counter example is enough to deny IPv6 operational. Really? With the Internet wide scope, yes, of course. So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? Reductio ad absurdum -DMM
Re: Big Temporary Networks
William Herrin wrote: OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. Hi Masataka, Where do things go wrong? OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Wifi station to station communications comprises a relatively minor portion of wifi's use so we don't burn a lot of worry on them in the general analysis. OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. In IPv6, the station sends an ICMPv6 router solicitation instead of an ARP for the default gateway. This is a multicast message but since it's from the station to the AP it's subject to layer 2 error recovery by the 802.11 protocol. The default gateway sends back a router advertisement (unicast since its responding to a solicitation) Unicast since its responding to a solicitation? RFC4861 states: A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. and a comment in rtadvd on the solicited advertisement: /* * unicast advertisements * XXX commented out. reason: though spec does not forbit it, unicast * advert does not really help In the reverse direction, Poor SLAAC with a lot of configured states is unnecessarily a lot more complex than simply bidirectional ARP, because it must involve all the distributed states of all the hosts on the link. What did I miss? Where does IPv6 take the bad turn that IPv4 avoided? If you still want to defend IPv6, you must say multicast RA and DAD are unnecessary features of IPv6, which means the current IPv6 is broken. Masataka Ohta
Re: Big Temporary Networks
On Sep 13, 2012, at 7:29 AM, Jay Ashworth wrote: I'm talking to the people who will probably be, in 2015, running the first Worldcon I can practically drive to, in Orlando, at -- I think -- the Disney World Resort. I've told them how critical the issue is for this market; they, predictably, replied We look forward to your patch. :-} So I just want to point out that this is an utterly irrelevant topic. Worldcon is full to the brim with really smart people who can build good networks, but in every place large enough to host a Worldcon the owners of the building make money selling Internet access and don't want competition. The very best we've been able to do was create an Internet Lounge with good connectivity, and even that isn't acceptable at most locations. So this really is an irrelevant topic, unless you want to create an LTE network with good connectivity near the location and sell bandwidth via that. (Phones and tablets outnumber laptop computers by a facter of 20:1 at scifi conventions) Off-topic: FWIW Hellsinki is a hell of a lot more likely. Remember that the membership votes on where to go, and Orlando really doesn't top anyone's list. Especially since Orlando keeps blowing off the very legitimate concerns that other people have raised about the location, including that Disney takes a dim view of anyone except their own paid actors wearing costumes, and more importantly the lack of inexpensive food options. If for some reason Hellsinki's bid falls apart, Spokane has better facilities and good LTE network support. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: Tech had a person managing the feed to DragonCon from the dedicated room w/ the polycomm video conference system, for panels, in addition to the actual union operator of the camera such. The camera ops had to be union? Hmmm. Ah, Chicago. Yes. That has been true everywhere that Worldcon has been for a number of years, excluding Japan. Hotel union contracts generally forbid activity being done by any non-union people, even if they are the guests. Yes, and I'm told by my best friend who did attend (I didn't make it this year) that the hotel wired/wifi was essentially unusable, every time he tried. Hence my interest in the issue. Always is. Those networks are not built for that many devices attaching. They never are. But they don't want the competition either. If you NEED connectivity at the convention, you must bring your own LTE MIFI and take care of yourself. This is simply not solvable in the convention hotel contracts level. I've got many SMOF friends and I've been trying for years, and it only worked for a small gap of years before hotels starting seeing Internet as a profit vector. Unfortunately, the size requirements of things the size of Worldcon limit the choices enough that this simply can't be a bargaining point. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
On Sep 14, 2012, at 1:55 PM, Jay Ashworth wrote: That's an interesting question indeed. The optimal solution here, of course, would be for Worldcons -- which are planned 3-4 years in advance -- to get the right technical people in the loop with the property to see when in the next 2 years (after a bid is confirmed) they plan to upgrade the networking they have now... and make sure it will tolerate a real worst case. The business case for the property, of course, is that they're more salable to large technical conferences -- which makes them more money. Question is, is it enough. Those people are already in the loop. Hi. Nice to see you again, Jay :) Unfortunately, as I've said in the previous two messages, it simply isn't something that can be changed. If you are running a small convention that can fit into a dozen hotels in the city, you can make them compete on multiple levels including network. Since there are less than 4 cities in the world who could host a worldcon in more than one facility, there's zero competition. * And frankly, the hotel contracts people have bigger problems to solve--namely, getting to use metric tons of convention floor space without paying much, if any money. Worldcon memberships are $150 each unless you wait until the last minute. This is a problem that large technical conferences with thousand dollar memberships can solve. They have money to throw at the hotel. Not fan-run conventions whose entire budget is less than the spare capital that Usenix keeps in their account. (I've seen both and can state this as a positive fact.) * The one place that competition can occur is in the bidding process. Part of what we all ask bid committees is about the network access at the location. And we vote based on what we can find out. However, the number of us who vote that way are fairly small, as most attendees have other priorities like inexpensive food options, cheaper hotel options, etc. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 8:16 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: William Herrin wrote: In IPv6, the station sends an ICMPv6 router solicitation instead of an ARP for the default gateway. This is a multicast message but since it's from the station to the AP it's subject to layer 2 error recovery by the 802.11 protocol. The default gateway sends back a router advertisement (unicast since its responding to a solicitation) Unicast since its responding to a solicitation? RFC4861 states: A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. Ah, okay. So the IPv6 router usually responds to router discovery with multicast where arp would have responded with unicast. This multicast message is not subject to 802.11's layer 2 error recovery so as previously discussed it has a high probability of being lost during some relatively ordinary wifi usage scenarios. But correct me if I'm wrong: the router advertisement daemon could be altered to reply with unicast without changing the standard, right? What do the radvd and rtadvd developers say about this when confronted with the 802.11 multicast problem? Are there any Internet drafts active in the IETF to replace that MAY with a SHOULD, noting that replying with multicast can defeat layer 2 error recovery needed for the successful use of some layer 1 media? What did I miss? Where does IPv6 take the bad turn that IPv4 avoided? If you still want to defend IPv6, you must say multicast RA and DAD are unnecessary features of IPv6, which means the current IPv6 is broken. I have no interest in defending IPv6. We're network operators here. You just told us (and offered convincing reasoning) that when selecting a router vendor for use with an IPv6 wifi network, one of our evaluation check boxes should should be, Responds to ICMPv6 router solicitation with a unicast message? Yes or Fail. And when we provide the list of deficiencies to our vendor and wave the wad of cash around, one of them should be, Responds to ICMPv6 router solicitations with a multicast packet - unreliable in a wifi environment. That's strikes me as something valuable to know. Far more valuable than, Dood, IPv6 has problems on wifi networks. So, let's keep going. IPv6 falls down compared to IPv4 on wifi networks when it responds to a router solicitation with a multicast (instead of unicast) router advertisement. Where else does it fall down compared to the equivalent behavior in an IPv4 wifi network? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
On 18/09/2012 21:24, William Herrin wrote: IPv6 falls down compared to IPv4 on wifi networks when it responds to a router solicitation with a multicast (instead of unicast) router advertisement. You mean it has one extra potential failure mode in situations where radio retransmission doesn't deal with the packet loss - which will cause RA to retry. Fall down is a slight overstatement. Nick
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett jrh...@netconsonance.com wrote: On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: Tech had a person managing the feed to DragonCon from the dedicated room w/ the polycomm video conference system, for panels, in addition to the actual union operator of the camera such. The camera ops had to be union? Hmmm. Ah, Chicago. Yes. That has been true everywhere that Worldcon has been for a number of years, excluding Japan. Hotel union contracts generally forbid activity being done by any non-union people, even if they are the guests. http://en.wikipedia.org/wiki/Right-to-work_law ''A right-to-work law is a statute that prohibits union security agreements, or agreements between labor unions and employers that govern the extent to which an established union can require employees' membership [...] as a condition of employment. Right-to-work laws exist in twenty-three U.S. states,'' Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 4:31 PM, Nick Hilliard n...@foobar.org wrote: On 18/09/2012 21:24, William Herrin wrote: IPv6 falls down compared to IPv4 on wifi networks when it responds to a router solicitation with a multicast (instead of unicast) router advertisement. You mean it has one extra potential failure mode in situations where radio retransmission doesn't deal with the packet loss - which will cause RA to retry. Fall down is a slight overstatement. Potayto, potahto. Like I said, I have no interest in defending IPv6. But I'm very interested in how to implement an IPv6 network that's as or more reliable than the equivalent IPv4 network. That makes me interested in the faults which get in the way. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: Big Temporary Networks
The trick is that there is no right to work if you are a guest at the hotel. You have no right to work on their property without their consent. In reality, the hotels do not want union headaches so that is the way it goes. Right to work only is in effect if an employer hires me and I do not want to join the union. Steven Naslund -Original Message- From: William Herrin [mailto:b...@herrin.us] Sent: Tuesday, September 18, 2012 3:48 PM To: Jo Rhett Cc: NANOG Subject: Re: Big Temporary Networks On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett jrh...@netconsonance.com wrote: On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: Tech had a person managing the feed to DragonCon from the dedicated room w/ the polycomm video conference system, for panels, in addition to the actual union operator of the camera such. The camera ops had to be union? Hmmm. Ah, Chicago. Yes. That has been true everywhere that Worldcon has been for a number of years, excluding Japan. Hotel union contracts generally forbid activity being done by any non-union people, even if they are the guests. http://en.wikipedia.org/wiki/Right-to-work_law ''A right-to-work law is a statute that prohibits union security agreements, or agreements between labor unions and employers that govern the extent to which an established union can require employees' membership [...] as a condition of employment. Right-to-work laws exist in twenty-three U.S. states,'' Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 5:12 PM, Naslund, Steve snasl...@medline.com wrote: The trick is that there is no right to work if you are a guest at the hotel. You have no right to work on their property without their consent. In reality, the hotels do not want union headaches so that is the way it goes. IIRC when the Democatic National Convention was held in Denver in 2008, they had to strike a special deal with the venue to bring in union labor instead of the normal workers because they couldn't find a suitable place that was already union. Conversely, when I went to IETF in Minneapolis a few years ago the networking folks simply took over the hotel network for the week. IETF attendee or not, you got wired Internet in your room courtesy of the conference. As I understand it, they convinced the hotel with the simple expedient of paying what they would ordinarily earn from a week's Internet charges. My point is that blaming union contracts or union anything for being unable to find a place to hold a convention where you can implement the network you want to implement is nonsense. NANOG, ARIN and IETF conferences have all somehow managed to implement their own effective networks. Even in union towns. If Worldcon's site selection committee can't find a suitable host, that's their deficiency. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
NOTE: None of the following content can be typed into your router. It holds information only slightly relevant to networking. On Sep 18, 2012, at 1:47 PM, William Herrin wrote: That has been true everywhere that Worldcon has been for a number of years, excluding Japan. Hotel union contracts generally forbid activity being done by any non-union people, even if they are the guests. http://en.wikipedia.org/wiki/Right-to-work_law ''A right-to-work law is a statute that prohibits union security agreements, or agreements between labor unions and employers that govern the extent to which an established union can require employees' membership [...] as a condition of employment. Right-to-work laws exist in twenty-three U.S. states,'' Well, Bill, this starts the legal dance equivalent of patches accepted, that being you are welcome to sue against this with your own money. Not being aware of which states have this law, it's entirely possible that the intersection between states that have this law and states which have enough scifi fans willing to get together to host a worldcon is negligible. I can only recall ~9 states which have hosted a worldcon in the last 30 years. Checking the easily found references pages seems to confirm this although I didn't bother checking extensively. I'm closely associated and personal friends with people who have done the hotel negotiations for four of the recent worldcons, and on a first name basis with most of the others, and this union requirement has been a major problem with most if not all of them. Just getting a waiver to allow people to serve drinks in their own hotel rooms has been hard enough to break many bids. It is currently impossible in San Francisco due to hotel contracts, and part of why Worldcon will never return to San Francisco unless very unlikely changes happen. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
From: William Herrin b...@herrin.us Date: Tue, 18 Sep 2012 16:47:34 -0400 Subject: Re: Big Temporary Networks On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett jrh...@netconsonance.com wrote: On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: Tech had a person managing the feed to DragonCon from the dedicated room w/ the polycomm video conference system, for panels, in addition to the actual union operator of the camera such. The camera ops had to be union? Hmmm. Ah, Chicago. Yes. That has been true everywhere that Worldcon has been for a number of years, excluding Japan. Hotel union contracts generally forbid activity being done by any non-union people, even if they are the guests. http://en.wikipedia.org/wiki/Right-to-work_law ''A right-to-work law is a statute that prohibits union security agreements, or agreements between labor unions and employers that govern the extent to which an established union can require employees' membership [...] as a condition of employment. Right-to-work laws exist in twenty-three U.S. states,'' 'Right to work', as defined by section 14 B of the Taft-Hartley Act, only prevents a union contract that requiures union membership as a PRE-REQUISITE for being hired. What is called 'closed shop' -- where employment is closed to those who are not union members. It does -not- prevent a 'union ship' -- where employees are required to join the union within a reasonable period =after= being hired. Right-to-work also does not prevent an organization from requiring, by contractual agreement, that third parties performing work ON THE 0ORGANIZATION'S PREMISES, employ union labor for _that_ work. It cannot specify _what_ union (or local) however. bTW, I'm a card-carrying member, and official, of the (independant) Amalgamated Tinkerers and Gadgeteers, anyone interested in setting up their own local is invited to contact me. *GRIN*
Re: Big Temporary Networks
On Sep 18, 2012, at 2:38 PM, William Herrin wrote: IIRC when the Democatic National Convention was held in Denver in 2008, they had to strike a special deal with the venue to bring in union labor instead of the normal workers because they couldn't find a suitable place that was already union. I can provide people who can refute that, but I don't have (or care about) the details enough to bother quoting them. I can say that Worldcon was in Denver the proceeding week, and we could only get one hotel about a half mile from the convention center to allow us to serve drinks in our own rooms without a union person there to serve them. So I have personal experience to doubt your story. Conversely, when I went to IETF in Minneapolis a few years ago the networking folks simply took over the hotel network for the week. IETF attendee or not, you got wired Internet in your room courtesy of the conference. As I understand it, they convinced the hotel with the simple expedient of paying what they would ordinarily earn from a week's Internet charges. IETF is considerably smaller event that Worldcon, and as such can play ball with smaller hotels. Worldcons haven't fit into hotels in more than 20 years*, and must negotiate with the convention centers -- and are not able to leverage room nights in the balance. * They tried with the large Hyatt in Chicago this year and got the worst of both worlds. The rooms were overfull far beyond standing room only, and they still couldn't get a hotel contract with good internet, accessibility or issue handling. My point is that blaming union contracts or union anything for being unable to find a place to hold a convention where you can implement the network you want to implement is nonsense. NANOG, ARIN and IETF conferences have all somehow managed to implement their own effective networks. Even in union towns. If Worldcon's site selection committee can't find a suitable host, that's their deficiency. Money speaks here. The budgets for NANOG conferences are posted, as are some of the worldcon committee budgets. RTFM. And again, even though Worldcons have significantly less money, the largest Nanog ever was still smaller than the smallest worldcon in the last 20 years. Smaller == more choices of hotels == negotiating ability. Please stop trying to be a smartass about something you could research, but haven't bothered to do so. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 6:14 PM, Jo Rhett jrh...@netconsonance.com wrote: Not being aware of which states have this law, it's entirely possible that the intersection between states that have this law and states which have enough scifi fans willing to get together to host a worldcon is negligible. There were enough fans among the 600,000 folks in the Baltimore area but not enough an hour away among the 5,600,000 in the National Capital Region to justify hosting a Worldcon a couple miles inside the Virginia border where no unions would get in your way? Really? I'm closely associated and personal friends with people who have done the hotel negotiations for four of the recent worldcons, and on a first name basis with most of the others, and this union requirement has been a major problem with most if not all of them. Tell 'em to look in a right to work state. Like Florida. http://www.nrtw.org/rtws.htm Just getting a waiver to allow people to serve drinks in their own hotel rooms has been hard enough to break many bids. It is currently impossible in San Francisco due to hotel contracts, and part of why Worldcon will never return to San Francisco unless very unlikely changes happen. California. NOT a right to work state. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: 'Right to work', as defined by section 14 B of the Taft-Hartley Act, only prevents a union contract that requiures union membership as a PRE-REQUISITE for being hired. What is called 'closed shop' -- where employment is closed to those who are not union members. It does -not- prevent a 'union ship' -- where employees are required to join the union within a reasonable period =after= being hired. The Taft-Hartley Act outlawed closed shops nationwide. It further authorized individual states to outlaw union shops and/or agency shops. 23 states, including my fine home state of Virginia, have done so. Right-to-work also does not prevent an organization from requiring, by contractual agreement, that third parties performing work ON THE 0ORGANIZATION'S PREMISES, employ union labor for _that_ work. It cannot specify _what_ union (or local) however. In Illinois, which has not enacted a state right-to-work law, that's correct. In Virginia, which has, there was just recently a big hullabaloo where the airports authority tried (and spectacularly failed) to place a union preference rule in their contracting process where bids from union shops would have a 10% preference versus bids from non union shops. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 6:44 PM, Jo Rhett jrh...@netconsonance.com wrote: On Sep 18, 2012, at 2:38 PM, William Herrin wrote: IIRC when the Democatic National Convention was held in Denver in 2008, they had to strike a special deal with the venue to bring in union labor instead of the normal workers because they couldn't find a suitable place that was already union. I can provide people who can refute that, but I don't have (or care about) the details enough to bother quoting them. Well you would know, you were working for the Democratic National Committee back when they selected Denver and started working the logistics. No, wait, that was actually me. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks (Dreamforce)
Anyone from nanog currently at the wheel of the conference network at Dreamforce in San Francisco (nearly 7 attendees)? It appears that all of the suggestions posted to this nanog thread so far were thoroughly ignored. Conference WiFi is effectively unusable, despite the very visible, expensive-looking enterprisey APs on temporary stands sprinkled throughout the conference. As far as I can tell, they're doing NAT, using a /16 per AP (which could amount to 5,000 or more devices in one broadcast domain depending on the location!), and are using what appear to be omnidirectional antennas at full blast power instead of zoning with tight directionals. Wifi is nearly unusable; even Sprint's crappy 3G coverage is faster and more reliable inside the conference halls.. -- RPM
Re: Big Temporary Networks
There were enough fans among the 600,000 folks in the Baltimore area but not enough an hour away among the 5,600,000 in the National Capital Region to justify hosting a Worldcon a couple miles inside the Virginia border where no unions would get in your way? Really? Having grown up and started my career in Virginia, and much of my family still lives there, I can assure that that there isn't a single facility in Virginia capable of hosting a Worldcon. I think DC has another common problem, where it's either not big enough, or too big for something with only 7k attendees. AND, Virginia has the exact same problem with hotel contracts. I was part of the convention running teams there in the late 80s and early 90s too. Same problems, same discussions. Same negotiations. At this point I think at this point your right to work wishful thinking has been thoroughly debunked by others. Let's drop this topic. To bring it back on topic, even if we didn't have unions to deal with, there's no law that can force a hotel or convention center to provide access to the facilities necessary for providing wifi or LTE access to the guests. You can only do that when you have negotiating power, and then you get back to there's usually only one possible choice and they know it -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
On Tue, Sep 18, 2012 at 6:44 PM, Jo Rhett jrh...@netconsonance.com wrote: On Sep 18, 2012, at 2:38 PM, William Herrin wrote: IIRC when the Democatic National Convention was held in Denver in 2008, they had to strike a special deal with the venue to bring in union labor instead of the normal workers because they couldn't find a suitable place that was already union. I can provide people who can refute that, but I don't have (or care about) the details enough to bother quoting them. Well you would know, you were working for the Democratic National Committee back when they selected Denver and started working the logistics. No, wait, that was actually me. Ah, then you shouldn't have said IIRC now should you? That expressly indicates you may or may not recall something you read/heard/etc. But since you do know the details of that, then pray tell which hotels they brought in union workers at? Because I'd love to see how that played out. Or were you talking about some other type of facility that we weren't discussing? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Big Temporary Networks
From: William Herrin b...@herrin.us Date: Tue, 18 Sep 2012 19:04:22 -0400 Subject: Re: Big Temporary Networks On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: 'Right to work', as defined by section 14 B of the Taft-Hartley Act, only prevents a union contract that requiures union membership as a PRE-REQUISITE for being hired. What is called 'closed shop' -- where employment is closed to those who are not union members. It does -not- prevent a 'union ship' -- where employees are required to join the union within a reasonable period =after= being hired. The Taft-Hartley Act outlawed closed shops nationwide. It further authorized individual states to outlaw union shops and/or agency shops. 23 states, including my fine home state of Virginia, have done so. False to fact on the last point. Many of the right-to-work states do -not- proscribe union shops. Thoe that do, almost invariably allow for an automatic/involuntary payroll deduction from non-union members covered by a collective bargaining agreement, payable to the union involved, which was a pro rata share of the direct costs of negotiting the collective agreement. Right-to-work also does not prevent an organization from requiring, by contractual agreement, that third parties performing work ON THE 0ORGANIZATION'S PREMISES, employ union labor for _that_ work. It cannot specify _what_ union (or local) however. In Illinois, which has not enacted a state right-to-work law, that's correct. Illinois, not having right-to-work, is irrelevant.grin In IOWA, where I grew up, and which has one of the strongest right-to-work laws in the country, union shops _are_ legal. As are 'on-site' union labor requirements. The family business (PR consulting) was heavily involved with the state Manufacturers Association (and the national org), and several other associations of large employers. I had access to *LOTS* of detailed info on the state of right-to-work, and collective- bargaining practices nation-wide. My remarks apply to the vast majority of right-to-work states. In Virginia, which has, there was just recently a big hullabaloo where the airports authority tried (and spectacularly failed) to place a union preference rule in their contracting process where bids from union shops would have a 10% preference versus bids from non union shops. Government entities run into all sorts of difficulties with _any_ such 'preference' biases in the bidding/contracting process -- there are statutory requirements to accept the lowest-price 'qualified' bid, with lots of supporting case law on 'fiduciary responsibility' of public monies -- _unless_ there is a demonstrable _compelling_ public policy reason to include scuh a preference. *VERY* few such survive a court challenge -- a 'set-aside' of a portion of the contracts for the 'preferred' group tends to have an equivalent effect and is much less expensive to implement. (a few percentage points on, say, 10-15% of the contracts is *far* less wasteful than circa 10% on _all_ contracts) I don't know of _any_ such bidding/contract 'preference' that has -not- been challenged in the courts. By a 'discrimminated against' vendor, in the case of government enditie, or by shareholders, in the case of private entities. I don't _think_ anybody has challenged hiring preferences for U.S. armed forces veterans, but I wouldn't be surprised if it _had_ been.
Re: Big Temporary Networks
Ok, as exciting as this all has been, it's grossly off topic now. Please retire the conversation to direct emails if you all want to keep arguing over it, m'kay? Thanks... -george On Tue, Sep 18, 2012 at 5:18 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: From: William Herrin b...@herrin.us Date: Tue, 18 Sep 2012 19:04:22 -0400 Subject: Re: Big Temporary Networks On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: 'Right to work', as defined by section 14 B of the Taft-Hartley Act, only prevents a union contract that requiures union membership as a PRE-REQUISITE for being hired. What is called 'closed shop' -- where employment is closed to those who are not union members. It does -not- prevent a 'union ship' -- where employees are required to join the union within a reasonable period =after= being hired. The Taft-Hartley Act outlawed closed shops nationwide. It further authorized individual states to outlaw union shops and/or agency shops. 23 states, including my fine home state of Virginia, have done so. False to fact on the last point. Many of the right-to-work states do -not- proscribe union shops. Thoe that do, almost invariably allow for an automatic/involuntary payroll deduction from non-union members covered by a collective bargaining agreement, payable to the union involved, which was a pro rata share of the direct costs of negotiting the collective agreement. Right-to-work also does not prevent an organization from requiring, by contractual agreement, that third parties performing work ON THE 0ORGANIZATION'S PREMISES, employ union labor for _that_ work. It cannot specify _what_ union (or local) however. In Illinois, which has not enacted a state right-to-work law, that's correct. Illinois, not having right-to-work, is irrelevant.grin In IOWA, where I grew up, and which has one of the strongest right-to-work laws in the country, union shops _are_ legal. As are 'on-site' union labor requirements. The family business (PR consulting) was heavily involved with the state Manufacturers Association (and the national org), and several other associations of large employers. I had access to *LOTS* of detailed info on the state of right-to-work, and collective- bargaining practices nation-wide. My remarks apply to the vast majority of right-to-work states. In Virginia, which has, there was just recently a big hullabaloo where the airports authority tried (and spectacularly failed) to place a union preference rule in their contracting process where bids from union shops would have a 10% preference versus bids from non union shops. Government entities run into all sorts of difficulties with _any_ such 'preference' biases in the bidding/contracting process -- there are statutory requirements to accept the lowest-price 'qualified' bid, with lots of supporting case law on 'fiduciary responsibility' of public monies -- _unless_ there is a demonstrable _compelling_ public policy reason to include scuh a preference. *VERY* few such survive a court challenge -- a 'set-aside' of a portion of the contracts for the 'preferred' group tends to have an equivalent effect and is much less expensive to implement. (a few percentage points on, say, 10-15% of the contracts is *far* less wasteful than circa 10% on _all_ contracts) I don't know of _any_ such bidding/contract 'preference' that has -not- been challenged in the courts. By a 'discrimminated against' vendor, in the case of government enditie, or by shareholders, in the case of private entities. I don't _think_ anybody has challenged hiring preferences for U.S. armed forces veterans, but I wouldn't be surprised if it _had_ been. -- -george william herbert george.herb...@gmail.com
Re: Big Temporary Networks
So I just want to point out that this is an utterly irrelevant topic. Worldcon is full to the brim with really smart people who can build good networks, but in every place large enough to host a Worldcon the owners of the building make money selling Internet access and don't want competition. The very best we've been able to do was create an Internet Lounge with good connectivity, and even that isn't acceptable at most locations. when you borrow $5,000 from the bank, they own you. when you borrow $5,000,000, you own them. large conferences throw more weight and usually can do their own network. ymmv, of course. randy
Re: Big Temporary Networks
On 17/09/2012 00:42, Masataka Ohta wrote: OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. So, what you're saying here is that a wifi network with lots of packet loss will cause connectivity problems with ipv6? Nick
Re: Big Temporary Networks
Nick Hilliard wrote: OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. So, what you're saying here is that a wifi network with lots of packet loss You don't understand CSMA/CA at all. There aren't so much packet losses except for broadcast/multicast packets. Masataka Ohta
Re: Big Temporary Networks
* joe...@bogus.com (joel jaeggli) [Sun 16 Sep 2012, 18:42 CEST]: We tend to engineer for a maximum of around 50 associations per radio (not AP). beyond that performance really starts to suck which can be measured along a multitude of dimensions. The most visible one to the client(s) being latency due to loss and subsequent retransmission. Reduction in coverage is done on a couple of dimensions. that ap with the 3-5dBi gain dipoles probably shouldn't be 100mW. but the noise floor is in a different place when the room is full of clients so it can't be to low either. Dropping the low speed rates backward compatibility with 802.11b and setting the multicast rate to something higher will force clients in marginal coverage situations to roam more quickly, hog the air less and allow for higher throughput. This is all good advice that you should implement. The difficulty with high user density deployments is getting stations to associate to the nearest access point on the optimal band. When presented with the same SSID for 2.4 and 5 GHz, clients usually prefer te 2.4 GHz one because its S:N ratio usually seems better (inherent to the lower frequency). However, in practice this isn't always the case as there usually are many more clients on 2.4. Various vendors of lighweight access points use tricks to get clients to associate on the 5 GHz band: e.g. Cisco, I think, will reject an initial association request at 2.4 GHz in the hope that the client will retry at 5 GHz before retrying at 2.4, which will both be accepted. -- Niels.
Re: Big Temporary Networks
On Sun, Sep 16, 2012 at 7:42 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: ARP and DHCP usually work. For an unusual case of ARP for other STAs, collisions do increase initial latencies, but as refreshes are attempted several times, there will be no latter latencies. OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. Hi Masataka, Where do things go wrong? As I understand it from your description, we're mostly talking about data between a wifi station and remote servers somewhere off the wired side of the network. Wifi station to station communications comprises a relatively minor portion of wifi's use so we don't burn a lot of worry on them in the general analysis. In the wifi to remote wired case, all IPv4 traveling the wifi network is subject to layer-2 error recovery except for the ARP packet from the default gateway to the station, requesting the station's MAC address. This works out OK because the default gateway is somewhat noisy about resending that arp request until it gets a response from the station and then it caches the response for a long time. In IPv6, the station sends an ICMPv6 router solicitation instead of an ARP for the default gateway. This is a multicast message but since it's from the station to the AP it's subject to layer 2 error recovery by the 802.11 protocol. The default gateway sends back a router advertisement (unicast since its responding to a solicitation) with prefix info, its MAC, its IP address, etc. Unicast = layer 2 error recovery. It then configures its address and sends packets to the default gateway. In the reverse direction, the gateway sends a neighbor solicitation via multicast looking for the MAC association with the station's IP. Like the ARP broadcast this is not subject to layer-2 error recovery. When the station eventually receives one of the repeated solicitations, it responds with a neighbor advertisement to the default gateway (station to AP, error recovered) which the default gateway caches for a while. In terms of the number and nature of packets sent without wifi's layer 2 error recovery, they look the same, at least in theory. What did I miss? Where does IPv6 take the bad turn that IPv4 avoided? Thanks, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Sat, Sep 15, 2012 at 01:11:54PM -0500 Quoting Jimmy Hess (mysi...@gmail.com): On 9/15/12, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Mans Nilsson wrote: I am not suggesting that. I'm just trying to point out that there might be a bunch of assumptions that aren't as true anymore when a lot of client connections share both source and destination address, and perhaps also destination port. If this happens simultaneously when a large amount of other tcp connections are NATed through the same box, resource starvation will occur. Assumptions that are already broken in Enterprise networks where 100+ users may share an IP snip LONG description of fragile b0rkendeness applied to a perfectly working network without NAT just so that NAT can be used to break it even more Warum einfach, wenn es auch kompliziert geht? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ... signature.asc Description: Digital signature
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Sat, Sep 15, 2012 at 10:15:26PM -0400 Quoting Eric Adler (eapt...@gmail.com): Are you working with locally originated video or video that originates as DVB-T? I'm looking at a similar project to replace NTSC distribution around the facility where I work (locally originated, DVB-S[2] receive, ATSC receive, and even NTSC receive) with an IP multicast system. I'd be interested in discussing options, caveats, and nuance further with all of those interested but I fear we're drifting off-topic for this list (and this thread). The only real problem is rights. The tech is easy. Get a last years PC, install as much tuners as you need, and install the right software. First google hit, more or less: http://wiki.arts.usyd.edu.au/meta/index.php/Building_a_DVB_streaming_server -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Should I start with the time I SWITCHED personalities with a BEATNIK hair stylist or my failure to refer five TEENAGERS to a good OCULIST? signature.asc Description: Digital signature
Re: Big Temporary Networks
- Original Message - From: Masataka Ohta mo...@necom830.hpcl.titech.ac.jp Jay Ashworth wrote: You're saying that *receiving* multicast streams over WLAN works poorly? Multicast/broadcast over congested WLAN works poorly, because there can be no ACK. That is, multicast/broadcast packets lost by collisions are never sent again. Well, yes, but that wasn't what Bill was talking about. He was talking about AP's being nice to associated clients who are in powersave mode, at the expensive of all the other connected clients, by buffering multicast packets until one or more DTIM frames are sent. We expect live streams to drop a packet here and there; that's what buffering is for... and why television proper still exists. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
- Original Message - From: Gaurab Raj Upadhaya gau...@lahai.com So you're *REALLY* motivated on this reduce the coverage thing, then. you could say yes :), reduce the coverage per-AP. Most APs I have seen will start failing with about ~100 associations and not to forget about the max GE uplink they have. that's about 40-50 people at most (being optimist). Really? 100 associations? On enterprise/carrier grade gear? Seriously? g) we have a /32 and /20 (v6 and v4 respectively) address space assigned by APNIC for this and other events in Asia (including the APNIC meeting itself) so we use that. We used to have a v4 /16 though before runout. I'm talking to someone from the Interop team; they have a dedicated /8. They gave that 45/8 back and kept 2 x /16 for themselves. I did not know that. Good on 'em. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
On 9/16/12 9:24 AM, Jay Ashworth wrote: - Original Message - From: Gaurab Raj Upadhaya gau...@lahai.com So you're *REALLY* motivated on this reduce the coverage thing, then. you could say yes :), reduce the coverage per-AP. Most APs I have seen will start failing with about ~100 associations and not to forget about the max GE uplink they have. that's about 40-50 people at most (being optimist). Really? 100 associations? On enterprise/carrier grade gear? Seriously? We tend to engineer for a maximum of around 50 associations per radio (not AP). beyond that performance really starts to suck which can be measured along a multitude of dimensions. The most visible one to the client(s) being latency due to loss and subsequent retransmission. Reduction in coverage is done on a couple of dimensions. that ap with the 3-5dBi gain dipoles probably shouldn't be 100mW. but the noise floor is in a different place when the room is full of clients so it can't be to low either. Dropping the low speed rates backward compatibility with 802.11b and setting the multicast rate to something higher will force clients in marginal coverage situations to roam more quickly, hog the air less and allow for higher throughput. g) we have a /32 and /20 (v6 and v4 respectively) address space assigned by APNIC for this and other events in Asia (including the APNIC meeting itself) so we use that. We used to have a v4 /16 though before runout. I'm talking to someone from the Interop team; they have a dedicated /8. They gave that 45/8 back and kept 2 x /16 for themselves. I did not know that. Good on 'em. Cheers, -- jra
Re: Big Temporary Networks
On 14/09/2012 12:38, Paul Thornton wrote: Veering slightly off-topic for NANOG, but is this worth taking onto the address policy mailing list ahead of RIPE65 to ensure people who aren't in the WG session are aware of the issue - and can therefore support (or question) any proposed changes? I just posted to ap-wg about this: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-September/007183.html Nick
Re: Big Temporary Networks
Jay Ashworth wrote: Well, yes, but that wasn't what Bill was talking about. He was talking about AP's being nice to associated clients who are in powersave mode, at the expensive of all the other connected clients, by buffering multicast packets until one or more DTIM frames are sent. I know. But, there are other reasons why multicast over WLAN behaves poorly. Thus, protocols heavily depending on broadcast/multicast, such as ND, will suffer. Masataka Ohta
Re: Big Temporary Networks
On 16/09/2012 19:30, Masataka Ohta wrote: Thus, protocols heavily depending on broadcast/multicast, such as ND, will suffer. ok, you've trolled me enough to ask why ND is worse than ARP on a wavelan network - in your humble opinion? Nick
Re: Big Temporary Networks
Nick Hilliard wrote: Thus, protocols heavily depending on broadcast/multicast, such as ND, will suffer. ok, you've trolled me enough to ask why ND is worse than ARP on a wavelan network - in your humble opinion? Because, with IPv4: 1) broadcast/multicast from a STA attacked to an AP is actually unicast to the AP and reliably received by the AP (and relayed unreliably to other STAs). That is, a broadcast ARP request from the STA to the AP is reliably received by the AP. 2) the AP knows MAC and IP addresses of STAs 3) ARP and DHCP replies are usually unicast ARP and DHCP usually work. For an unusual case of ARP for other STAs, collisions do increase initial latencies, but as refreshes are attempted several times, there will be no latter latencies. OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. Masataka Ohta
Re: Big Temporary Networks
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: Nick Hilliard wrote: Thus, protocols heavily depending on broadcast/multicast, such as ND, will suffer. ok, you've trolled me enough to ask why ND is worse than ARP on a wavelan network - in your humble opinion? Because, with IPv4: 1) broadcast/multicast from a STA attacked to an AP is actually unicast to the AP and reliably received by the AP (and relayed unreliably to other STAs). That is, a broadcast ARP request from the STA to the AP is reliably received by the AP. 2) the AP knows MAC and IP addresses of STAs 3) ARP and DHCP replies are usually unicast ARP and DHCP usually work. For an unusual case of ARP for other STAs, collisions do increase initial latencies, but as refreshes are attempted several times, there will be no latter latencies. OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. Masataka Ohta
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Fri, Sep 14, 2012 at 09:40:02AM -0400 Quoting Jay Ashworth (j...@baylink.com): - Original Message - From: Måns Nilsson mansa...@besserwisser.org 12:20:33AM -0700 Quoting Octavio Alvarez (alvar...@alvarezp.ods.org): I'd have expected someone to have QoS mentioned already, mainly to put FTP and P2P traffic on the least important queues and don't hog up the net. As long as there is no multicast entering the wlan this is best solved by getting more bandwidth. Well, we'll be on the *sending* end of the Hugo's, but... ;-) It would still be nice to multicast them inside our network (and out to whomever wants to watch), but what the heck's the consumer-level client side of multicast video streaming look like these days? IIRC a number of IETF meetings were badly maimed in the wireless side until people remembered that the WLAN was no place for multicast video. VLC does mcast really nice. We're testing it for replacing antenna distribution systems and DVB-T receivers at work. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production of the INDONESIAN archipelago? signature.asc Description: Digital signature
Re: Big Temporary Networks
On 13 Sep 2012, at 17:32, Tim Franklin t...@pelican.org wrote: You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM minimum. Or not. The CCC presentation is showing *real* Internet for everyone, unless I'm very much mistaken… Absolutely. NAT is too fragile/expensive/non-performant for these setups. CGN boxes are too new to be economically borrowed/rented, maybe one day it will be possible, but for now we can still get the address space required (Timespan issues notwithstanding) On 13 Sep 2012, at 21:03, Chris Boyd cb...@gizmopartners.com wrote: If you know of an ISP in Central Texas that can deploy a 10Mbit plus connection along with a /22 of v4 address space for a 1 day event, please let me know. TWCable has been pretty easy to work with for special events, but I'd be really surprised to see them be able to do that. I suggest either getting a L2 circuit or else IPIP/GRE tunnel to somewhere with a functioning internet market. It is far preferable to tunnel than it is to have session state in the network. I've been part of the team deploying networking to various leafy parts of the Netherlands (e.g. HAR2009), ex-soviet airbases (CCC Camp), a park in Milton Keynes, UK (EMF2012). With some thought and creative planning it is possible to bring in a useful uplink in the 300M-10G+ range. [I'm not sure I remember those DS3s and OC3s that other posters are talking about, something these days used only in developing countries i thought ;-)] As a network engineer, these events are a great way to meet people with different experience, talk to eager young folk, do things in a different way and generally have a reset on your professional life. You might even get some sun too :-)
Re: Big Temporary Networks
Mans Nilsson wrote: Do not NAT. When all those people want to do social networking to the same furry BBS while also frequenting three social app sites simultaneously you are going to get Issues if you NAT. So don't. I am not suggesting that. I'm just trying to point out that there might be a bunch of assumptions that aren't as true anymore when a lot of client connections share both source and destination address, and perhaps also destination port. If this happens simultaneously when a large amount of other tcp connections are NATed through the same box, resource starvation will occur. Then, an advise better than yours is Chris's: : with small budgets. : You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM : minimum. Run your DNS resolver and DHCP here, unless you have : hardware to spare. : Bandwidth. Lots of Bandwidth. posted before yours. If public address space is available, it is better to use that. It depends on budgets and other factors. Also, no NAT means there will be no session timers for things like long lived low bandwidth tcp sessions. Assuming no NAT firewalls without very large connection tables, not necessarily. Masataka Ohta
Re: Big Temporary Networks
On 9/15/12, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Mans Nilsson wrote: I am not suggesting that. I'm just trying to point out that there might be a bunch of assumptions that aren't as true anymore when a lot of client connections share both source and destination address, and perhaps also destination port. If this happens simultaneously when a large amount of other tcp connections are NATed through the same box, resource starvation will occur. Assumptions that are already broken in Enterprise networks where 100+ users may share an IP What you can use is an edge device with a large NAT table, 3 entries at least; setup a policy that limits each private IP address to 50 simultaneous TCP connections, to protect NAT device against malware-infected laptops, You might also use a wireless AP and Ethernet switches with PVLAN (or protected port bridging) and DHCP snooping functionality, then configure to restrict attached devices from sending or receiving any kind of IP or Ethernet broadcast traffic with other hosts on the LAN, And ensure the NAT/Firewall device will not route traffic from the Inside interface back to the Inside interface, so the NAT device and DHCP server are the only units that attached nodes may communicate with. Use a short NAT timeout period for UDP (30 seconds), so there is a certain number of users that your NAT device can service, depending on its CPU power and NAT table size. You can calculate an upper bound for required NAT table capacity, based on number of users, and number of allowed connections per user. Then take your total number of users, Divide by say 20, and build a NAT pool with that many public IP addresses, For example: one /24 of public IP addresses per 5000 users. to accomplish on average 20 users per public IP, providing you pick a NAT/Firewall device balances internal private to public IP usage fairly evenly. -- -JH
Re: Big Temporary Networks
- Original Message - From: Måns Nilsson mansa...@besserwisser.org It would still be nice to multicast them inside our network (and out to whomever wants to watch), but what the heck's the consumer-level client side of multicast video streaming look like these days? IIRC a number of IETF meetings were badly maimed in the wireless side until people remembered that the WLAN was no place for multicast video. VLC does mcast really nice. We're testing it for replacing antenna distribution systems and DVB-T receivers at work. Then you want to know that the HD HomeRun people, Silicon Dust, have versions of their tuners that will generate multicast, I would suspect. You're saying that *receiving* multicast streams over WLAN works poorly? Can you expand on that? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
On Sat, Sep 15, 2012 at 9:18 PM, Jay Ashworth j...@baylink.com wrote: You're saying that *receiving* multicast streams over WLAN works poorly? I don't have any experience with it, but here's what Google told me: http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html When any single wireless client associated with an access point has 802.11 power-save mode enabled, the access point buffers all multicast frames and sends them only after the next DTIM (Delivery Traffic Indication Message) beacon, which may be every one, two, or three beacons (referred to as the “DTIM interval”). [...] default 100 millisecond beacon interval http://www.wi-fiplanet.com/tutorials/article.php/3433451 all it takes is one wireless client using 802.11 power saving to cause the access point to buffer multicast frames for all clients, and you may not be able to control whether or not users switch on power save mode. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big Temporary Networks
- Original Message - From: William Herrin b...@herrin.us On Sat, Sep 15, 2012 at 9:18 PM, Jay Ashworth j...@baylink.com wrote: You're saying that *receiving* multicast streams over WLAN works poorly? I don't have any experience with it, but here's what Google told me: http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html When any single wireless client associated with an access point has 802.11 power-save mode enabled, the access point buffers all multicast frames and sends them only after the next DTIM (Delivery Traffic Indication Message) beacon, which may be every one, two, or three beacons (referred to as the “DTIM interval”). [...] default 100 millisecond beacon interval Thanks for doing my googling for me, Bill. :-) I'll do some more; I would sort've expect that might be something the firmware in enterprise-class APs would handle better (where by better, I mean not permitting one client to manhandle the entire network :-). Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
Jay Ashworth wrote: You're saying that *receiving* multicast streams over WLAN works poorly? Multicast/broadcast over congested WLAN works poorly, because there can be no ACK. That is, multicast/broadcast packets lost by collisions are never sent again. Masataka Ohta
Re: Big Temporary Networks
On Thu, 13 Sep 2012 14:45:55 -0700, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Måns Nilsson mansa...@besserwisser.org 04:05:41PM + Quoting Dylan Bouterse (dy...@corp.power1.com): I'm not sure if this is obvious for this list or not, but with your WiFi nodes, a good practice for that kind of density is more nodes, lower power. Keep the client connection load per AP as low as possible to improve overall performance. Jacking up the power in a small area like that will just step on the adjacent APs and cause issues. I'd have expected someone to have QoS mentioned already, mainly to put FTP and P2P traffic on the least important queues and don't hog up the net. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Thu, Sep 13, 2012 at 05:45:55PM -0400 Quoting Jay Ashworth (j...@baylink.com): - Original Message - At all possible cost, avoid login or encryption for the wireless. Yes, and no. snip Just keep in mind that every action you make the visitors have to perform to get Internet connectivity is a support workload. (For example, I have no problems blocking outbound port 25 and redirecting recursive DNS -- though I do want a system that permits me to whitelist MACs on request. But I would do those on the guest and dealer nets, and not on the staff one.) Remember that DNSSEC breaks quite easily if you redirect DNS and since this is three years in the future, the uptake on DNSSEC may well have hit the point where there is visual feedback on validation in client UI. While things have become much better, doing 802.1x on conference wireless probably is a bit daring. OTOH eduroam does it all over Europe. If I did try to do that, it would probably only be on the staff network; it's a much more contrained environment. It'll work much better there, and FWIW, will be a little yet perhaps effective speedbump for intruders. And get v6. Yeah, I assumed that, though it will be interesting to see how much play it actually gets; these are SF geeks, not networking geeks. Again, even in North America, the uptake may well have accelerated enough that it is To Be Expected. Besides, IME, SF geeks are computer savvy more than others. Oh yeah. I'm fond of leases as short as 30 minutes, though if I have a /16, I won't care as much. A couple hours will get the user over a lunch break if not overnight, which means that long TCP sessions survive on Proper Computers (that don't tear down TCP on link loss. I'm looking at you, Microsoft!). This is Really Nice. Open up computer from sleep and press enter in xterm and ssh session is up. (my personal record is for telnet, an untouched connection survived two taxi trips, one night, some NATed wlan at the hotel and when i got back to the right network I just plugged the cable in and continued in the same session. But I cheated and had fixed addresses.) Very nice, Måns; thanks. My pleasure. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 He is the MELBA-BEING ... the ANGEL CAKE ... XEROX him ... XEROX him -- signature.asc Description: Digital signature
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Fri, Sep 14, 2012 at 12:20:33AM -0700 Quoting Octavio Alvarez (alvar...@alvarezp.ods.org): I'd have expected someone to have QoS mentioned already, mainly to put FTP and P2P traffic on the least important queues and don't hog up the net. As long as there is no multicast entering the wlan this is best solved by getting more bandwidth. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... the HIGHWAY is made out of LIME JELLO and my HONDA is a barbequeued OYSTER! Yum! signature.asc Description: Digital signature
Re: Big Temporary Networks
To all folks running NOC's at events like CCC/Assembly/DEFCON/etc: hats off, and enjoy the fun ;) On 2012-09-14 09:34 , Måns Nilsson wrote: [..] A couple hours will get the user over a lunch break if not overnight, which means that long TCP sessions survive on Proper Computers (that don't tear down TCP on link loss. I'm looking at you, Microsoft!). While that is a default, one can actually disable the Media Sensing: One of the first google hits on disable media sense: http://www.windowsnetworking.com/articles_tutorials/Disable-Media-Sense-TCPIP-Windows-XP.html And voila, your connections keep open even if you change from wired to wireless, as long as you get the same IP on both or if you unplug the cable and plug it in a bit later etc. Now if that works over sleep that is something I am not sure of, I rarely let computers go into sleep mode (long live NoSleep on OSX). Typically people who require that though will settle for the use of mosh (http://mosh.mit.edu/) apparently. Greets, Jeroen
Re: Big Temporary Networks
On Thu, 13 Sep 2012, Jay Ashworth wrote: Get lots of IP addresses. A /16 probably still can be borrowed for this kind of event. I know RIPE had rules and addresses for this kind of use a couple years ago, at least. Indeed? I did not see that coming. Hell, perhaps Interop could be talked into loaning me a /16. :-) dons Interop hatYou might think you are joking, but if it doesn't overlap with an existing commitment, we can probably make that happen./dons -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Re: Big Temporary Networks
On Fri, 14 Sep 2012, Brandon Ross wrote: On Thu, 13 Sep 2012, Jay Ashworth wrote: Get lots of IP addresses. A /16 probably still can be borrowed for this kind of event. I know RIPE had rules and addresses for this kind of use a couple years ago, at least. Indeed? I did not see that coming. Hell, perhaps Interop could be talked into loaning me a /16. :-) dons Interop hatYou might think you are joking, but if it doesn't overlap with an existing commitment, we can probably make that happen./dons I don't know about last /8 policy and how that will change this, but so far I have seen little problem getting a temporary /16 or alike for events from RIPE. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big Temporary Networks
On 13/09/2012 21:32, Måns Nilsson wrote: Get lots of IP addresses. A /16 probably still can be borrowed for this kind of event. I know RIPE had rules and addresses for this kind of use a couple years ago, at least. yes, you can get a bunch of IP addresses from the ripe ncc if you only need them on a temporary basis: http://www.ripe.net/ripe/docs/ripe-526 They've allocated a /14 for this purpose, so this would be well more than enough to cope with most large conferences. Nick
Re: Big Temporary Networks
On 14 September 2012 11:16, Nick Hilliard n...@foobar.org wrote: On 13/09/2012 21:32, Måns Nilsson wrote: Get lots of IP addresses. A /16 probably still can be borrowed for this kind of event. I know RIPE had rules and addresses for this kind of use a couple years ago, at least. yes, you can get a bunch of IP addresses from the ripe ncc if you only need them on a temporary basis: http://www.ripe.net/ripe/docs/ripe-526 We tried to apply using this policy to get address space for EMFCamp, no good in reality. The RIPE hostmaster would only allocate us address space 7 days before the event started, needed longer than this to begin building out the network which span multiple data centres. Especially with time, access and change freeze constraints due to the Olympics this year. They didn't seem to want to budge on this, easier in my opinion to borrow some off a friendly organisation or ISP than jump hoops with RIPE. Only other option would be to build your infra out in an existing spare /24 you can get hold of - put router loopbacks, point to points etc in there. Then a week before the event attempt to get the larger /19 assignment from RIPE to put your clients in. I wouldn't be happy doing that though, as in my opinion it doesn't leave enough time for any reachability testing / debugging. -- Nat http://natmorris.co.uk http://twitter.com/natmorris
Re: Big Temporary Networks
On 14/09/2012 11:50, Nat Morris wrote: The RIPE hostmaster would only allocate us address space 7 days before the event started, needed longer than this to begin building out the network which span multiple data centres. Especially with time, access and change freeze constraints due to the Olympics this year. They didn't seem to want to budge on this, easier in my opinion to borrow some off a friendly organisation or ISP than jump hoops with RIPE. I'm in the process of trying to get this changed. To be completely fair on the RIPE NCC, they don't have flexibility on this issue - the original policy was broken. Nick
Re: Big Temporary Networks
On 14 September 2012 11:54, Nick Hilliard n...@foobar.org wrote: On 14/09/2012 11:50, Nat Morris wrote: The RIPE hostmaster would only allocate us address space 7 days before the event started, needed longer than this to begin building out the network which span multiple data centres. Especially with time, access and change freeze constraints due to the Olympics this year. They didn't seem to want to budge on this, easier in my opinion to borrow some off a friendly organisation or ISP than jump hoops with RIPE. I'm in the process of trying to get this changed. To be completely fair on the RIPE NCC, they don't have flexibility on this issue - the original policy was broken. This is good news Nick :) I have spoken to others in the past few weeks who were hoping to raise it at the next RIPE meeting. I am happy to share our ticket details with you off list if it'll help. -- Nat http://natmorris.co.uk http://twitter.com/natmorris
Re: Big Temporary Networks
* Nick Hilliard They've allocated a /14 for this purpose, so this would be well more than enough to cope with most large conferences. It's actually a /13 (151.216.0.0/13). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Re: Big Temporary Networks
On Fri, 14 Sep 2012, Tore Anderson wrote: It's actually a /13 (151.216.0.0/13). It used to be in another place (I don't remember exactly, this was 5-8 years ago). Nice that they have a /13 nowadays anyway, I'd imagine there are more temporary events nowadays. I've used it a couple of times and then a week was sufficient (start rigging on monday, everything done by thursday morning where 5000 people show up with their computers (this was mainly 10/100 ports, people brought their own cables), teardown and turning off the network, and then returning the space to RIPE on monday. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big Temporary Networks
On 14/09/2012 12:11, Mikael Abrahamsson wrote: I've used it a couple of times and then a week was sufficient (start rigging on monday, everything done by thursday morning where 5000 people show up with their computers (this was mainly 10/100 ports, people brought their own cables), teardown and turning off the network, and then returning the space to RIPE on monday. Realistically, the timescales specified in the policy are too short. As there is no ability for the RIPE NCC to pre-assign the space (i.e. let you know in advance what address range you'll be getting, but not give you the go-ahead to use it), it can make it extremely difficult for conference organisers to work within the specified timescales. Also, 1 week is not suitable for debogonisation. I will be talking about this at the address policy working group session at RIPE65. It shouldn't be too difficult to fix the problem, so long as it's clear what people actually need from these temporary addresses. Nick
Re: Big Temporary Networks
On Fri, 14 Sep 2012, Nick Hilliard wrote: Also, 1 week is not suitable for debogonisation. Could you please elaborate on this aspect? Who would be treating this space as a bogon, and why? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big Temporary Networks
On 14/09/2012 12:19, Nick Hilliard wrote: On 14/09/2012 12:11, Mikael Abrahamsson wrote: I've used it a couple of times and then a week was sufficient (start rigging on monday, everything done by thursday morning where 5000 people show up with their computers (this was mainly 10/100 ports, people brought their own cables), teardown and turning off the network, and then returning the space to RIPE on monday. I will be talking about this at the address policy working group session at RIPE65. It shouldn't be too difficult to fix the problem, so long as it's clear what people actually need from these temporary addresses. Veering slightly off-topic for NANOG, but is this worth taking onto the address policy mailing list ahead of RIPE65 to ensure people who aren't in the WG session are aware of the issue - and can therefore support (or question) any proposed changes? Paul. -- Paul Thornton
Re: Big Temporary Networks
Måns Nilsson wrote: And get v6. Do not NAT. When all those people want to do social networking to the same furry BBS while also frequenting three social app sites simultaneously you are going to get Issues if you NAT. So don't. Don't? Considering that, ten years ago, some computers were still often shared by thousands of people distinguished by their port numbers and that, today, pseudo ISPs are using NAT, it is not only wrong but also impossible to identify a user only by his IP address without port numbers. Masataka Ohta
Re: Big Temporary Networks
Subject: Re: Big Temporary Networks Date: Fri, Sep 14, 2012 at 09:22:01PM +0900 Quoting Masataka Ohta (mo...@necom830.hpcl.titech.ac.jp): Måns Nilsson wrote: And get v6. Do not NAT. When all those people want to do social networking to the same furry BBS while also frequenting three social app sites simultaneously you are going to get Issues if you NAT. So don't. Don't? Considering that, ten years ago, some computers were still often shared by thousands of people distinguished by their port numbers and that, today, pseudo ISPs are using NAT, it is not only wrong but also impossible to identify a user only by his IP address without port numbers. Ohta-san, I am not suggesting that. I'm just trying to point out that there might be a bunch of assumptions that aren't as true anymore when a lot of client connections share both source and destination address, and perhaps also destination port. If this happens simultaneously when a large amount of other tcp connections are NATed through the same box, resource starvation will occur. If public address space is available, it is better to use that. Also, no NAT means there will be no session timers for things like long lived low bandwidth tcp sessions. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I think my career is ruined! signature.asc Description: Digital signature
Re: Big Temporary Networks
- Original Message - From: Sean Lazar kn...@toaster.net WLAN in large conferences certainly is a challenge. You basically want to get as many people on 5GHz as possible due to more available channels. 2.4GHz becomes quite noisy. And here you raise an interesting question: do dual band wifi clients *show which band a network is on*? Will they prefer the A band AP automatically in any way? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
- Original Message - From: Måns Nilsson mansa...@besserwisser.org 05:45:55PM -0400 Quoting Jay Ashworth (j...@baylink.com): - Original Message - At all possible cost, avoid login or encryption for the wireless. Yes, and no. snip Just keep in mind that every action you make the visitors have to perform to get Internet connectivity is a support workload. I understand entirely. That was the reason for my remember each MAC address for the entire event approach to captive portal. I forsee the guests entering a code from their event badge the first time they use each device. Unlike most events, I also forsee a single page How to use our Internet connectivity sheet that actually tells you what you need to know. :-) (For example, I have no problems blocking outbound port 25 and redirecting recursive DNS -- though I do want a system that permits me to whitelist MACs on request. But I would do those on the guest and dealer nets, and not on the staff one.) Remember that DNSSEC breaks quite easily if you redirect DNS and since this is three years in the future, the uptake on DNSSEC may well have hit the point where there is visual feedback on validation in client UI. Good point. While things have become much better, doing 802.1x on conference wireless probably is a bit daring. OTOH eduroam does it all over Europe. If I did try to do that, it would probably only be on the staff network; it's a much more contrained environment. It'll work much better there, and FWIW, will be a little yet perhaps effective speedbump for intruders. Was my plan, yes. This isn't, really, defcon. :-) And get v6. Yeah, I assumed that, though it will be interesting to see how much play it actually gets; these are SF geeks, not networking geeks. Again, even in North America, the uptake may well have accelerated enough that it is To Be Expected. Besides, IME, SF geeks are computer savvy more than others. I've heard that asserted. I'm not certain to what extent it's actually true. Oh yeah. I'm fond of leases as short as 30 minutes, though if I have a /16, I won't care as much. A couple hours will get the user over a lunch break if not overnight, which means that long TCP sessions survive on Proper Computers (that don't tear down TCP on link loss. I'm looking at you, Microsoft!). Well, I'm a firm believer in Least Recently Used, so as long as my DHCP block is larger than my userbase, everyone will have the same address all weekend anyway. This is Really Nice. Open up computer from sleep and press enter in xterm and ssh session is up. (my personal record is for telnet, an untouched connection survived two taxi trips, one night, some NATed wlan at the hotel and when i got back to the right network I just plugged the cable in and continued in the same session. But I cheated and had fixed addresses.) Nice. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
- Original Message - From: Måns Nilsson mansa...@besserwisser.org 12:20:33AM -0700 Quoting Octavio Alvarez (alvar...@alvarezp.ods.org): I'd have expected someone to have QoS mentioned already, mainly to put FTP and P2P traffic on the least important queues and don't hog up the net. As long as there is no multicast entering the wlan this is best solved by getting more bandwidth. Well, we'll be on the *sending* end of the Hugo's, but... ;-) It would still be nice to multicast them inside our network (and out to whomever wants to watch), but what the heck's the consumer-level client side of multicast video streaming look like these days? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
Once upon a time, Jay Ashworth j...@baylink.com said: Well, we'll be on the *sending* end of the Hugo's, but... ;-) You might want to talk to whoever did this year's WorldCon networking. I'm a Dragon*Con volunteer, and I know there was a some type of direct connection between Chicago (WorldCon) and Atlanta (Dragon*Con) so that we could show things like the Hugo ceremony (and I think we fed some video the other way as well, like the D*C Parade). I don't know how they did the regular Internet stream (except that it went through Ustream, who shut down the Hugo feed because of a DMCA complaint). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Big Temporary Networks
- Original Message - From: Chris Adams cmad...@hiwaay.net Once upon a time, Jay Ashworth j...@baylink.com said: Well, we'll be on the *sending* end of the Hugo's, but... ;-) You might want to talk to whoever did this year's WorldCon networking. I'm a Dragon*Con volunteer, and I know there was a some type of direct connection between Chicago (WorldCon) and Atlanta (Dragon*Con) so that we could show things like the Hugo ceremony (and I think we fed some video the other way as well, like the D*C Parade). I know some of that went on, yes, and certainly if I'm more formally involved, I'll be querying the SMOFlist to see who ran things at the last 5 or so. My bet is that none of them *had* a formal CTO/Ops person full time. (Though of course, now that I've said that, those people will pop up here, saying you talkin' to *me*?? :-) I don't know how they did the regular Internet stream (except that it went through Ustream, who shut down the Hugo feed because of a DMCA complaint). My understanding was that Dragon *took its main feed* for the Hugos via Ustream, and the entire room got left standing; no? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
Once upon a time, Jay Ashworth j...@baylink.com said: My understanding was that Dragon *took its main feed* for the Hugos via Ustream, and the entire room got left standing; no? I don't know; I wasn't in there, and I didn't find out about the Ustream cut until I was home. I would think I would have heard if the feed was cut though (I wasn't involved, but I work Techops and know the people involved). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Big Temporary Networks
- Original Message - From: Chris Adams cmad...@hiwaay.net Subject: Re: Big Temporary Networks Once upon a time, Jay Ashworth j...@baylink.com said: My understanding was that Dragon *took its main feed* for the Hugos via Ustream, and the entire room got left standing; no? I don't know; I wasn't in there, and I didn't find out about the Ustream cut until I was home. I would think I would have heard if the feed was cut though (I wasn't involved, but I work Techops and know the people involved). Noted. How big is that crew for Dragon; you were, what, 30k attendees? -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
- Original Message - From: Matthew Barr mb...@snap-interactive.com and as I was working the Hugo's: On Sep 14, 2012, at 10:14 AM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Chris Adams cmad...@hiwaay.net I know some of that went on, yes, and certainly if I'm more formally involved, I'll be querying the SMOFlist to see who ran things at the last 5 or so. My bet is that none of them *had* a formal CTO/Ops person full time. Tech had a person managing the feed to DragonCon from the dedicated room w/ the polycomm video conference system, for panels, in addition to the actual union operator of the camera such. The camera ops had to be union? Hmmm. Ah, Chicago. Yes. There was an IT head, but he was responsible for the laptops / staff network, printers, etc. Got it. The hotel itself had the conference wireless, instead of it being brought in. Yes, and I'm told by my best friend who did attend (I didn't make it this year) that the hotel wired/wifi was essentially unusable, every time he tried. Hence my interest in the issue. My understanding was that Dragon *took its main feed* for the Hugos via Ustream, and the entire room got left standing; no? Dragon took it's feed for the hugo's through Ustream, as did the *overflow* rooms onsite. It was easier to go to the internet back, than to get a direct cable. Ok, then I was correctly informed; thanks. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big Temporary Networks
Once upon a time, Jay Ashworth j...@baylink.com said: Noted. How big is that crew for Dragon; you were, what, 30k attendees? The estimate I heard was 52,000-55,000 paid attendees this year (plus another 3,000+ for volunteers, guests+spouse/agent/etc., press, etc.). Our Techops staff was around 240-250 this year. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Big Temporary Networks
In a message written on Fri, Sep 14, 2012 at 11:53:01AM -0400, Jay Ashworth wrote: Yes, and I'm told by my best friend who did attend (I didn't make it this year) that the hotel wired/wifi was essentially unusable, every time he tried. Hence my interest in the issue. I find more and more hotel networks are essentially unusable for parts of the day, conference or no. Of course, bring in any geek contingent with multiple devices and heavy usage patterns and the problems get worse. What I find most interesting is more often than not the problem appears to be an overloaded / undersized NAT/Captive portal/DNS Resolver system. Behaviors like existing connections working fine, but no new ones can be created (out of ports on the NAT?). While bandwidth is occasionally an issue, I've found an ssh tunnel out to some other end point solves the issues in 9 out of 10 cases. I wonder how many hotels upgrade their bandwidth but not the gateway, get a report that their DS-3/OC-3/Metro-E is only 25% used, and think all is well. Mean while half their clients can't connect to anything due to the gateway device. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpyboWnvCgz5.pgp Description: PGP signature
