Re: [gaia] Comments on: draft-irtf-gaia-alternative-network-deployments
Arjuna Sathiaseelan <arjuna.sathiaseelan@cl.cam.ac.uk> Mon, 11 April 2016 08:23 UTC
Return-Path: <arjuna.sathiaseelan@gmail.com>
X-Original-To: gaia@ietfa.amsl.com
Delivered-To: gaia@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403B512E8BE for <gaia@ietfa.amsl.com>; Mon, 11 Apr 2016 01:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeErfKrMB9Fp for <gaia@ietfa.amsl.com>; Mon, 11 Apr 2016 01:23:11 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EF612E8BB for <gaia@irtf.org>; Mon, 11 Apr 2016 01:23:10 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id e190so144266794lfe.0 for <gaia@irtf.org>; Mon, 11 Apr 2016 01:23:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=FPGt81K4tYj8C93aRjKtojpxmTZfgrZ8Q9fbm+cXR/0=; b=WA33Hz6HQs+MUHO6AM3uzGue27BGCPPeBWsPGIREEjEDZ6LA3Tx+ff5oGTwqunXLbl pxiBfldtYVKxIYvq8/XXZZCYbEUOu8aqotVs/F561LPD4F3XH1LWANplGn8UR9Vd2uAb RtOHB+hbTjRrD0SjiFLKMbf5vutasdekg1WrDHf91T47KWxrn0RZoFMS2jBfeW3oL9eC ENB3nJ/ZVfvJcnbs6L1nS1UUL4VIhNWhAAVX0NMRYQGnCH+iZif3w0QKr4SF62UwQUQr 2IS1NOsN/BnkwzhRP1/bu+OqoLDMkJLidm8ZPLJO/3oJ4MB/erHK9fBdIngstKBgUCsV RaIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FPGt81K4tYj8C93aRjKtojpxmTZfgrZ8Q9fbm+cXR/0=; b=IC76rFtSKN7udMmnRuaijMBWV4PHKbbGdDDP8RYqfmCw+xkRdolTGRGiiH5Nq+QKZn 8wmJZrKuoEf02lKAZVNB/HRF55qFnELoz4DZIAbis4hKHyqQ83+mpgikOLf93YoK63pw ak8h0zrfYMoMOnLToS7gqTR43ijaSIJj/hKWBFnqlLvR4WqVIn0httx1kf6E8PCa4+Go /8u30GmXoDEt22DEdaq9jVugLJt9pg79kyl7tYAqrbS20TWFCTD6niyzWjEuPk2Fyk0y TbzKk9VR+71e0fmGGUoUGndJFwRn8d9prj+VsGc3gguUQeIg3k7gs90wSrQVRqdsy7sL kngA==
X-Gm-Message-State: AD7BkJKIP+tJYvdmhcsvTZ/vsxZ3kITrUZO9zR5IM6caJnKOY8Tp8kWTkj0HjVdHgfVANsLMJ8MSqsfGI1Fz6w==
MIME-Version: 1.0
X-Received: by 10.25.17.67 with SMTP id g64mr8511272lfi.112.1460362988573; Mon, 11 Apr 2016 01:23:08 -0700 (PDT)
Sender: arjuna.sathiaseelan@gmail.com
Received: by 10.112.151.1 with HTTP; Mon, 11 Apr 2016 01:23:08 -0700 (PDT)
Received: by 10.112.151.1 with HTTP; Mon, 11 Apr 2016 01:23:08 -0700 (PDT)
In-Reply-To: <CAKLmikPYuSrE69e5neDxOu+5+aUUJm_=vknaZxx3yBsWzfBHvw@mail.gmail.com>
References: <CAKLmikPYuSrE69e5neDxOu+5+aUUJm_=vknaZxx3yBsWzfBHvw@mail.gmail.com>
Date: Mon, 11 Apr 2016 04:23:08 -0400
X-Google-Sender-Auth: rboOmauDwoB6fc-dPZVXfnwiA38
Message-ID: <CAPaG1Ak-0wReP4E_Yxd1eEdDB28wex9JEMBuchxthrze8JMamw@mail.gmail.com>
From: Arjuna Sathiaseelan <arjuna.sathiaseelan@cl.cam.ac.uk>
To: Mitar <mmitar@gmail.com>
Content-Type: multipart/alternative; boundary="001a11407b2a2d5bc9053031417f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gaia/US4ctR2CLxYQdmaZL4eNxiClNyI>
Cc: gaia <gaia@irtf.org>
Subject: Re: [gaia] Comments on: draft-irtf-gaia-alternative-network-deployments
X-BeenThere: gaia@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Global Access to the Internet for All <gaia.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/gaia>, <mailto:gaia-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gaia/>
List-Post: <mailto:gaia@irtf.org>
List-Help: <mailto:gaia-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/gaia>, <mailto:gaia-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2016 08:23:16 -0000
we did the same thing here with the publicaccesswifi deployment in Nottingham couple of years ago - http://www.cl.cam.ac.uk/~as2330/docs/dev12.pdf this eg is already in the draft. I think most of the reasoning you have given should already be in the draft.. arjuna On 11 Apr 2016 00:53, "Mitar" <mmitar@gmail.com> wrote: > Hi! > > I am participant in the open wireless network in Slovenia, wlan > slovenija (https://wlan-si.net/) and I am writing to provide some > feedback on the draft. I am glad people are working on it. My list of > comments is in no particular order, mostly in order of reading. I am > sorry if this will be long, but there are many issues with the draft. > > Section 4.2. I think this is a very limited set of motivations. From > our network and from my experience talking to other community > networks, I would claim that many share also much more altruistic > motivations. For example, our whole network is build around principle > that some of us have abundance of Internet connectivity at home > (FTTH), so we can share part of that openly with everyone. More of us > will share it, more people will have access to Internet. Of course > there are other motivations why people participate, and everyone has a > different mix of those motivations, but I definitely think that the > list should be extended to include: > > - free sharing of Internet connectivity, altruism > - various forms of activism (network neutrality guarantees, > anti-censorship, decentralization to minimize control, showing that > alternative is possible) > - building a new type of commons > - not being just a consumer, but active participant, wanting to have a > say in operations > - provide local services to local people, tighten/reconnect the > community (eg. http://tidepools.co/) > - provide alternative service in case of natural disasters and other > extreme situations > - wanting to have a space for experimentation and teaching of others, > empowering others to take their Internet connectivity into their own > hands > > An example of another network describing itself with much more of what > I am writing than what is currently on the list: > https://sudoroom.org/wiki/Mesh > > All those are goals and motivations (and those are just few I > remembered without much thinking) for many community networks. I do > not think the list in section 4.2 can ever be comprehensive, but I was > really taken aback from its economy-centric bias at the moment. Most > community networks do not operate on that level. It is of course > present, but there are some other primary motivations why people are > doing it. > > Section 4.4, technologies employed: > > "Low-cost optical fiber systems are used to connect households in some > villages." > > Isn't this section about list of technologies? Why are those villages > mentioned? Optical systems can also be used elsewhere. > > Moreover, in wlan slovenija we developed free optics free-space (no > fiber) system Koruza (http://koruza.net/), which are useful especially > in high-density urban environments because of no interference. > > Section 4.5, typical scenarios: > > I do not see usefulness of this categorization, because almost any > network I know of outgrow and changed through time inside all these > categories. Community networks maybe start somewhere (like urban or > rural area), but then they grow and spread over the whole country, > then start connecting with other countries. > > Section 5, classification of alternative networks: > > Introduction again focuses on incentives. That is a very limited > perspective. I would claim that most alternative networks go beyond > just incentives, but exist because of various beliefs: about how > networks should operate, who should have control over them, the > importance of commons and community stewardship of commons, etc. > > Section 5.1, community networks: > > As I explained, goals and motivation here seems a pretty limited list > and I think you should include at least ones I listed above. But > probably you should do a survey and ask community networks what are > their goals and motivations, instead of trying to guess them. (If you > have done such a survey, I would love to see data.) > > Technologies used: TDMA should be there, Ubiquiti gear does it by default. > > Typical scenarios: all > > Community Networks are large-scale: not necessary, they can also be > small, city only. Some are large scale, some are small, some are > focused on one region, some are distributed around larger region, > connected with VPN together. > > "There is a shared platform (e.g. a web site) where a minimum > coordination is performed. This way, community members with the right > permissions have an obvious and direct form of organizational control > over the overall operation of the network (e.g. IP addresses, > routing, etc.) in their community (not just their own participation in > the network)." > > This can be true, but it is not necessary so. There are community > networks with much larger focus on decentralization. Especially with > IPv6 a lot more autoconfiguraiton is possible. > > Also, phrase "this way" is strange in this context. I do not see how > control over the routing of the network has anything with the > existence of the shared platform? In wlan slovenija network we also > use a web shared platform, but that platform does not control the > network. It just helps in coordination. Network would operate even > without it, just people would have a bit harder time coordinate about > use of IP space, and learning how to configure their nodes. > > So having a shared platform can have very little to do with how core > network's resources (IP addresses, routings, peerings, DNS entries, > etc.) are managed. > > "A Community Network is a network in which any participant in the > system may add link segments to the network in such a way that the new > segments can support multiple nodes and adopt the same overall > characteristics as those of the joined network, including the capacity > to further extend the network. Once these link segments are joined to > the network, there is no longer a meaningful distinction between the > previous and the new extent of the network." > > Isn't this definition of the Internet? Just replace "segment" with > "autonomous system" and "community network" with "Internet". :-) > > So what exactly is the property which differentiates community > networks? Maybe there is none. Maybe community networks are simply > trying to (re)build the Internet, but this time having infrastructure > owned by participants, which are not just consumers, but are > participating. > > I think this is the most important characteristic. Organic growth, and > that people own the equipment, and thus the emergent network. This > should be more clearly explained. So it is not so much about > technology in community networks, but about who owns and controls > equipment (people/users/participants), and who coordinates the network > growth (people/users/participants). The line between users, providers, > participants, people gets blurred. > > "In Community Networks, everybody keeps the ownership of what he/she > has contributed. > > Not necessary. They can also give it away (for example equipment for > backbone nodes). In general, mostly people do not really track > ownership of equipment, because they do not care about ownership if it > is operating according to common principles. And if it is not, it > should not be in the network no matter who owns the equipment. > > Section 5.4, crowdshared approaches, led by the users and third party > stakeholders > > "VNOs pay the sharers and the network operators, thus creating an > incentive structure for all the actors: the end users get money for > sharing their network, the network operators are paid by the VNOs, who > in turn accomplish their socio-environmental role." > > I am not sure if all networks which can be grouped under this section > really do that. In the draft itself the https://openwireless.org/ > movement is listed, but no shares or money or any incentive structure > is in place there for people to share their extra Internet > connectivity. > > So I would change this paragraph to: > > "VNOs can be organized to pay the sharers and the network operators, > thus creating an incentive structure for all the actors: the end users > get money for sharing their network, the network operators are paid by > the VNOs, who in turn accomplish their socio-environmental role. But > VNOs can also operate on gift-economy principles, where participants > contribute to the commons by sharing their resources knowing that this > benefits all." > > Section 6.2.1, Media Access Control (MAC) protocols for wireless links > > "Wireless standards ensure interoperability and usability to those who > design, deploy and manage wireless networks." > > Wireless standard ensure low-cost of equipment due to economies of > scale and mass production. This is the main reason I think why WiFi is > so popular in alternative networks. You can get a device for $10. And > you can get this because everyone is producing this hardware, and the > hardware is not just made for the alternative networks. In contrast, > traditional ISPs use hardware which is developed only for them. Even > if they are big ISP, number of units is still much smaller than number > of WiFi routers produced for the global market. > > Question about list of WiFi standards in this draft. Why is that > needed? Why properties and descriptions of those standards should be > in this draft? They belong to Wikipedia, or their own standard. In > this draft we can just reference those standards. Like what of all > this text is relevant to alternative networks? It is general text > which is true for any use: > > "802.22 [IEEE.802-22.2011] is a standard developed specifically for > long range rural communications in TV white space frequencies and > first approved in July 2011. The standard is similar to the 802.16 > (WiMax) [IEEE.802-16.2008] standard with an added cognitive radio > ability. The maximum throughput of 802.22 is 22.6 Mbps for a single 8 > MHz channel using 64-QAM modulation. The achievable range using the > default MAC scheme is 30 km, however 100 km is possible with special > scheduling techniques. The MAC of 802.22 is specifically customized > for long distances - for example, slots in a frame destined for more > distant Consumer Premises Equipment (CPEs) are sent before slots > destined for nearby CPEs. > > Base stations are required to have a Global Positioning System (GPS) > and a connection to the Internet in order to query a geolocation > spectrum database. Once the base station receives the allowed TV > channels, it communicates a preferred operating white space TV channel > with the CPE devices. The standard also includes a coexistence > mechanism that uses beacons to make other 802.22 base stations aware > of the presence of a base station that is not part of the same > network." > > Section 7.1.2.2, mesh routing protocols > > "A large number of Alternative Networks use the Optimized Link State > Routing Protocol (OLSR) as defined in [RFC3626]." > > Not really. Networks use OLSR as implemented by http://olsr.org/, > which is far from the standardized OLSR in RFC3626. For example, in > practice, ETX metric is used, which is not even mentioned in RFC3626. > > Also Babel should definitely be mentioned, it is used in many > networks, and it is even (properly) standardized as RFC6126. So if you > want to include a routing protocol for alternative networks with IETF > standard, you should include this one for sure. > > Section 7.2.1, traffic management when sharing network resources > > It is interesting that so many people believe that there have to be > some special prioritization done for sharers to be able to use APs. > But it is not necessary true. Often people connecting to open AP nodes > will be much further away from the AP than the sharer. So often just > this distance already influences that the users of open network are > prioritized less (they have higher packet loss, lower bitrate, which > is also good to limit the lowest allowed bitrate). > > In community networks is also pretty common to run the network itself > on different frequencies than the APs. Some first generation mesh > networks ran everything (backbone over ad-hoc) and client-serving APs > on the same channel, but with 5 GHz spectrum and cheap dual-band > devices this is often separated now. > > Section 7.3., services provided > > What is this section? A non-comprehensive list of services on the > Internet and networks in general? This looks pretty useless section > which would not inform anyone reading this draft of anything about > alternative networks. > > If something, then it would be interesting to talk about specialized > services developed just for community/alternative networks: > > - Inter-network peering/VPNs: https://wiki.freifunk.net/IC-VPN > - Local wikis like: https://localwiki.org > - Community oriented portals: http://tidepools.co/ > - Network monitoring/deployment/maintenance platforms > - VoIP sharing between networks, allowing cheap calls between countries > - Sensor networks and citizen science build by adding sensors to devices > - Community radio/TV stations > > What is interesting that some networks do not even provide Internet > access. For example, in Croatia, historically, there were wireless > communities which made networks in villages just to be able to play > games. > > Section 7.3.2.1, web browsing proxies > > "Other services (file sharing, VoIP, etc.) are not usually allowed in > many Alternative Networks due to bandwidth limitations." > > That would go against net neutrality and anti-censorship principles > which are important in many other alternative networks. So the > question how informative this sentence is, because for some maybe this > is true, for some it is not, and some probably are build just around > this. Others probably address this with innovative solutions like > internal file servers. > > At the end, a general question, how would DIY ISPs > (https://www.diyisp.org/) be categorized according to this draft? To > me is unclear. > > Some more projects to look into, and think how they relate to this draft: > > https://rhizomatica.org/ > http://www.servalproject.org/ > http://villagetelco.org/ > > > Mitar > > -- > http://mitar.tnode.com/ > https://twitter.com/mitar_m > > _______________________________________________ > gaia mailing list > gaia@irtf.org > https://www.irtf.org/mailman/listinfo/gaia >
- [gaia] Comments on: draft-irtf-gaia-alternative-n… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Jose Saldana
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Stephen Farrell
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Niels ten Oever
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Steven G. Huter
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Arjuna Sathiaseelan
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Eggert, Lars
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Jon Crowcroft
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Mitar
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Jose Saldana
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… panayotis antoniadis
- Re: [gaia] Comments on: draft-irtf-gaia-alternati… Matthew Ford
- [gaia] current version: draft-irtf-gaia-alternati… Niels ten Oever
- Re: [gaia] current version: draft-irtf-gaia-alter… Jose Saldana