scott- nice to have you back amongst us! i think that we're basically on the same page here, although i don't know that we have the infrastructure to provide services on the level you've described. matt made some interesting comments which i thought were particularly apropos for our group, struggling with the whole AUP element as well as how to deal with freeloaders. i think that the consensus that the group has achieved thus far is: where folks are interested in offering hotspot access, they can. we as a group can work to come up with an authentication scheme to allow members acccess via whatever access points they can reach and share and share alike. how the overlay network foots up with folks that have dedicated internet access is a matter for further research. when last we saw our hero (Saturday, Aug 10, 2002), Scott Dier was madly tapping out: > After being off the list for a while I decided to read the archives a > bit for this month. I've read the thoughts about the network and I'm > pretty worried about this secnario: > > ISP sets up VPN server on network. > ISP offers pay-for-access model to anyone, but doesn't mention TCWUG, > just makes a pretty map. > Users have no knowledge of TCWUG and what the network is coming from > TCWUG gets -$0- and falls fast into disarray with glut of new users. > > I've also done some thinking on how to mitigate that situation and I've > come up with a bunch of blanks. Most of them revolve on how to provide > open access to individuals while denying abusive access. I think the > situation might be best worked out with the following: > > Two access levels, Supporting and Freeloader: > > Supporting pays money, perhaps yearly, perhaps monthly. They get equal > access along with any other supporters and in theory the money requested > assists with network upgrades to meet that demand. Some sort of QoS is > involved but is mostly non restrictive. Perhaps some way to provide a > minimum amount to each user, but the excess is first come first serve to > supporters. > > Freeloaders get essentially "Scavenger" access. It's run-off excess > energy from Supporters, Network Founders, Major Network Sponsors, Admins > and the sort. This way, the network can still be considered a public > service and potentially still a nonprofit (?) but just providing a > different level of service to those who pay. Scavenger access is an > idea that's been used in internet2 land to apply to specific > organizations 'non-primary-mission' traffic. More can be found here: > http://qbone.internet2.edu/qbss/ qbss - is essentially a fancy name put on DiffServ best effort traffic. i'd be all for this and we have the ability to do this on router platforms that support marking and passing with different priority traffic with DSCP codepoints. like you i'm not sure what the capabilities are for doing this under PC based router platforms. there are some challenges associated with doing this. all routers within the routing domain must support DiffServ and the appropriate per hop behaviours and the edge devices must know how to map a particular user (based on IP address or .1p tag) to a particular class of service. > Supporters who decide to stop paying become Freeloaders. No 'extra' > charges should be put on someone to make the conversion back and forth. > Either category should require a method of identification by an Admin to > recieve a login. Perhaps Freeloaders can be auth-free, but I'm worried > the abuse will get so bad it won't be worth it. Perhaps let auth-free > users only get to specific resources and other auth-free users. > > So, three levels of bits. Supporting users 'mandatory bandwidth > allocation' bits, Supporting users 'extra bandwidth thats available' > bits, and the Freeloaders scavenger bits. > > Of course, I have no experience implementing QBSS on anything yet. I've > yet had a chance to break the closest cisco router I've got my grubby > hands enabled on. And, I don't know what sort of QoS can be done on > Linux or *BSD to further these means. This sort of proposal also > assumes that we are looking at an embedded platform with either host_ap > or the freebsd (i think) non-free orinoco ap driver. I also assume that > a decently hard to avoid authentication protocol is used. as an aside - freebsd and openbsd provide the ability to get the queuing functionality with altq (openbsd supports pf which i believe supports marking). the marking functionality i haven't fully researched on either of these platforms. > I wish I could have made it to the recent meeting, but ran into issues > where I couldn't make it. (colo box drive finally took a dive, spent a > few hours with a friend configuring a new machine from scratch and > putting in the most recent backup. Luckily I was able to get the old > box to come up enough that I could rsync recent data to the new > machine.) -- steve ulrich sulrich at botwerks.org PGP: 8D0B 0EE9 E700 A6CF ABA7 AE5F 4FD4 07C9 133B FAFC