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
>