Re: Big Temporary Networks

[JÁKÓ András]

> > 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

[William Herrin]

On Sun, Sep 23, 2012 at 3:50 PM, JÁKÓ András  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[JÁKÓ András]

> 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

[Masataka Ohta]

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

[William Herrin]

On Fri, Sep 21, 2012 at 10:42 PM, Masataka Ohta
 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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Masataka Ohta]

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

[William Herrin]

On Thu, Sep 20, 2012 at 11:54 PM, Masataka Ohta
 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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Masataka Ohta]

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

[Masataka Ohta]

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]

> -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

[joel jaeggli]

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

[Jay Ashworth]

- Original Message -
> From: "Rick Alfvin" 

> 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

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> 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

[TJ]

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

[Masataka Ohta]

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

[David Miller]

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

[Masataka Ohta]

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

[TJ]

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

[Masataka Ohta]

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

[William Herrin]

On Wed, Sep 19, 2012 at 11:33 AM, Sean Harlow  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
 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
 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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Valdis . Kletnieks]

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

[Masataka Ohta]

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

[Masataka Ohta]

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

[Sean Harlow]

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

[TJ]

> 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

[Masataka Ohta]

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

[Måns Nilsson]

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

[Masataka Ohta]

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

[Seth Mos]

Op 18-9-2012 22:50, William Herrin schreef:

On Tue, Sep 18, 2012 at 4:31 PM, Nick Hilliard  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

[Randy Bush]

> 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

[George Herbert]

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  wrote:
>
>
>> From: William Herrin 
>> 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 
>> 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.
>
> 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

[Robert Bonomi]

> From: William Herrin 
> 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  
> 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.

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

[Jo Rhett]

> On Tue, Sep 18, 2012 at 6:44 PM, Jo Rhett  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

[Jo Rhett]

> 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 (Dreamforce)

[Ryan Malayter]

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

[William Herrin]

On Tue, Sep 18, 2012 at 6:44 PM, Jo Rhett  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[William Herrin]

On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[William Herrin]

On Tue, Sep 18, 2012 at 6:14 PM, Jo Rhett  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Jo Rhett]

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

[Robert Bonomi]

> From: William Herrin 
> 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  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

[Jo Rhett]

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

[William Herrin]

On Tue, Sep 18, 2012 at 5:12 PM, Naslund, Steve  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: 
Falls Church, VA 22042-3004

RE: Big Temporary Networks

[Naslund, Steve]

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 
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

[William Herrin]

On Tue, Sep 18, 2012 at 4:31 PM, Nick Hilliard  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[William Herrin]

On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Nick Hilliard]

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

[William Herrin]

On Tue, Sep 18, 2012 at 8:16 AM, Masataka Ohta
 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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Jo Rhett]

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

[Jo Rhett]

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

[Jo Rhett]

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

[Masataka Ohta]

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

[William Herrin]

On Sun, Sep 16, 2012 at 7:42 PM, Masataka Ohta
 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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Niels Bakker]

* 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

[Masataka Ohta]

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

[Nick Hilliard]

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

[Masatoshi Enomoto]

Masataka Ohta : 

>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]

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

[Nick Hilliard]

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

[Masataka Ohta]

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

[Nick Hilliard]

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

[joel jaeggli]

On 9/16/12 9:24 AM, Jay Ashworth wrote:

- Original Message -

From: "Gaurab Raj Upadhaya" 

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

[Jay Ashworth]

- Original Message -
> From: "Gaurab Raj Upadhaya" 

> > 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

[Jay Ashworth]

- Original Message -
> From: "Masataka Ohta" 

> 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

[Måns Nilsson]

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

[Måns Nilsson]

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  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



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

[Masataka Ohta]

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

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> On Sat, Sep 15, 2012 at 9:18 PM, Jay Ashworth  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

[William Herrin]

On Sat, Sep 15, 2012 at 9:18 PM, Jay Ashworth  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: 
Falls Church, VA 22042-3004

Re: Big Temporary Networks

[Jay Ashworth]

- Original Message -
> From: "Måns Nilsson" 

> > 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

[Jimmy Hess]

On 9/15/12, Masataka Ohta  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

[Masataka Ohta]

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

[Will Hargrave]

On 13 Sep 2012, at 17:32, Tim Franklin  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  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

[Måns Nilsson]

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" 
> 
> > 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

[Jay Ashworth]

- Original Message -
> From: "Leo Bicknell" 

> 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.

Neither part of that surprises me.  :-}

I'm *almost* convinced not to NAT IPv4, so far.

> 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.

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.

Or do I just overlay for the event.

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

[Leo Bicknell]

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

Re: Big Temporary Networks

[Chris Adams]

Once upon a time, Jay Ashworth  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 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Big Temporary Networks

[Jay Ashworth]

- Original Message -
> From: "Matthew Barr" 

> and as I was working the Hugo's:
> 
> On Sep 14, 2012, at 10:14 AM, Jay Ashworth  wrote:
> > - Original Message -
> >> From: "Chris Adams" 
> >
> > 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

[Jay Ashworth]

- Original Message -
> From: "Chris Adams" 

> Subject: Re: Big Temporary Networks
> Once upon a time, Jay Ashworth  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

[Chris Adams]

Once upon a time, Jay Ashworth  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 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Big Temporary Networks

[Jay Ashworth]

- Original Message -
> From: "Chris Adams" 

> Once upon a time, Jay Ashworth  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

[Chris Adams]

Once upon a time, Jay Ashworth  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 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Big Temporary Networks

[Jay Ashworth]

- Original Message -
> From: "Måns Nilsson" 

> 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

[Jay Ashworth]

- Original Message -
> From: "Måns Nilsson" 

> 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.
> 
> 
> 
> 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

[Jay Ashworth]

- Original Message -
> From: "Sean Lazar" 

> 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

[Måns Nilsson]

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

[Masataka Ohta]

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

[Paul Thornton]

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

[Mikael Abrahamsson]

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

[Nick Hilliard]

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

[Mikael Abrahamsson]

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

[Tore Anderson]

* 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

[Nat Morris]

On 14 September 2012 11:54, Nick Hilliard  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]

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

[Nat Morris]

On 14 September 2012 11:16, Nick Hilliard  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

[Nick Hilliard]

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

[Mikael Abrahamsson]

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.  :-)


You might think you are joking, but if it doesn't overlap 
with an existing commitment, we can probably make that happen.


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

[Brandon Ross]

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.  :-)


You might think you are joking, but if it doesn't 
overlap with an existing commitment, we can probably make that 
happen.


--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
Schedule a meeting:  https://tungle.me/bross Skype:  brandonross

Re: Big Temporary Networks

[Jeroen Massar]

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

[Måns Nilsson]

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

[Måns Nilsson]

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.

 

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