Re: [gaia] Difference between FON and a "manyfolks Community Network"

Steve Song <stevesong@nsrc.org> Thu, 19 June 2014 11:36 UTC

Return-Path: <stephen.song@gmail.com>
X-Original-To: gaia@ietfa.amsl.com
Delivered-To: gaia@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537231A018E for <gaia@ietfa.amsl.com>; Thu, 19 Jun 2014 04:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 Zc1U73VqHC2Z for <gaia@ietfa.amsl.com>; Thu, 19 Jun 2014 04:36:16 -0700 (PDT)
Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECDC1A0139 for <gaia@irtf.org>; Thu, 19 Jun 2014 04:36:16 -0700 (PDT)
Received: by mail-ve0-f169.google.com with SMTP id pa12so2170014veb.14 for <gaia@irtf.org>; Thu, 19 Jun 2014 04:36:14 -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:content-type; bh=DBw2iaisqa+TFj3N+3dWifmv7A2yXB0APYfKM8kPEy8=; b=VNChNDItyF6JezdaiOvibIUYBiUxHlRHHmJx8JoqZHyKuohrOZ3GDpSsVZX7RPUjGy Lqz2Gl7swhulB4Kf+1pLnl1VeXCc1oM2HTx+ZYMvbqfBJoKOD5p53/jEmeM8cTiI/YEG gMMB7C5FUP7YRzVk4xJWBZO9X8GlJOxwgeiNo7mwWplPxM1QCnv3OuERqsGDJ/RA/crl XG/ZiMRToEcSgEI0GMLb8yFAZHi88K/fLagZNJgU6nPonxtKdZMpw/YIvhSHRjk5Eg4k ZYDHaNXuBRJXeR7xdET9EnfR4z19oAWJW/Ki6yLWKg/RkFr+ibezZRWYPFogSxjHHw0t VfeQ==
MIME-Version: 1.0
X-Received: by 10.221.42.135 with SMTP id ty7mr3588607vcb.14.1403177774508; Thu, 19 Jun 2014 04:36:14 -0700 (PDT)
Sender: stephen.song@gmail.com
Received: by 10.220.224.20 with HTTP; Thu, 19 Jun 2014 04:36:14 -0700 (PDT)
In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914001B23795A@SABRE.InterDigital.com>
References: <CAKoiRubiqVC3C3SBq+jGnxc5fcuFSdeWztFMJy7RBFkmVW+rOw@mail.gmail.com> <61CAF342FE1EE34EAC8FB19B765914001B23795A@SABRE.InterDigital.com>
Date: Thu, 19 Jun 2014 08:36:14 -0300
X-Google-Sender-Auth: Dr1CDWweaCQE4WvAuAaHKjLAeY8
Message-ID: <CAD_CWO0usw3RzObLHmQ=xnJLELx-n+_Bpu4p_zmKq7VskXsQJQ@mail.gmail.com>
From: Steve Song <stevesong@nsrc.org>
To: gaia <gaia@irtf.org>
Content-Type: multipart/related; boundary="001a11339974cee16a04fc2ec819"
Archived-At: http://mailarchive.ietf.org/arch/msg/gaia/5hK5rBXLqDae9ZujG2jzDHeyuMA
Subject: Re: [gaia] Difference between FON and a "manyfolks Community Network"
X-BeenThere: gaia@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Global Access to the Internet for All <gaia.irtf.org>
List-Unsubscribe: <https://irtf.org/mailman/options/gaia>, <mailto:gaia-request@irtf.org?subject=unsubscribe>
List-Archive: <http://irtf.org/mail-archive/web/gaia/>
List-Post: <mailto:gaia@irtf.org>
List-Help: <mailto:gaia-request@irtf.org?subject=help>
List-Subscribe: <https://irtf.org/mailman/listinfo/gaia>, <mailto:gaia-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jun 2014 11:36:21 -0000

Hi all,

I like the idea of user-extensibility as a principle.  I was coming at this
from the point of view of decentralised, locally owned and operated
networks.  I think it roughly amounts to the same thing.

Taking it down yet another level, the key motivation for me in encouraging
the decentralisation of network development is increasing "agency", in the
sense intended by Amartya Sen[1], for individuals and communities.  What
that translates to from a broadband perspective is the ability of
individuals and communities to act to change their own connectivity status.
 It also translates to the ability to consolidate demand to increase buying
power whether through collective, community initiatives or through local
entrepreneurship.

I would like to emphasise that there is arguably more policy and regulatory
work that needs to be done to enable this than technological innovation.
 This can be illustrated by the simple fact that point-to-point WiFi, which
most of us take for granted, is not free (as in beer) in most sub-Saharan
African countries.  License fees are often many times the cost of the
equipment.  Other things like network license exemption for non-profits or
cooperatives are other frontiers worth pursuing.

Looking at this from another angle, there is also the notion of increasing
overall network resilience (I actually mean antifragility here but that is
perhaps another discussion) through diversity of access and through
decentralisation.  While this is arguably a technological issue, it is also
fairly politically charged.  I raise this in the spirit of getting all my
"issues" out on the table.  :)

Cheers... Steve

[1] https://en.wikipedia.org/wiki/Capability_approach#Agency


On 19 June 2014 05:54, Trossen, Dirk <Dirk.Trossen@interdigital.com> wrote:

>  Rohan, all,
>
>
>
> I cannot help but notice that the discussion on definitions already
> reveals core principles that this community sees at the heart of their work
> - so good to see this discussion but necessary to capture these various
> viewpoints more distinctively as 'principles'.
>
>
>
> As for your definition, Rohan:
>
> User-extensible network: A network in which any participant in the system
> may add link segments to the network in such a way that the new network
> 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
> extent of the network and the new extent of the network.
>
>
>
> I wonder how my 'passive infrastructure' based DSL or cable network fits
> in here. Let's start from scratch: a housing community (e.g., in the middle
> of London) will add link segments to the network, often through a
> commercial offering. If it is a new development, cables need to be pulled
> and laid in the new development, again often through an (open?) access
> provider. If it is an existing development, the existing cable
> infrastructure is likely re-used, although at the network level you are
> repeating the process of 'add link segments' by re-activating, e.g., the
> DSL line to the apartment(s). So a standard BT OpenReach+Retail ISP way of
> doing things seem to be fitting under that definition, doesn't it?
>
>
>
> Nevertheless, as pointed out in the beginning, your very definition
> entails a set of principles for 'building networks' that is worthwhile
> capturing as such.
>
>
>
> Best,
>
>
>
> Dirk
>
>
>
> *From:* gaia [mailto:gaia-bounces@irtf.org] *On Behalf Of *Rohan Mahy
> *Sent:* 19 June 2014 07:15
> *To:* gaia@irtf.org
> *Subject:* [gaia] Difference between FON and a "manyfolks Community
> Network"
>
>
>
> Hi Everyone,
>
>
> Just to briefly introduce myself, my most relevant experience to this
> group is that I helped build a large portion of a long-range 5Ghz WiFi
> backbone in Haiti with Inveneo; before that I was an active participant in
> the IETF in the RAI space for many years; currently I work as a field
> logistician for an international non-profit in South Kivu, Democratic
> Republic of Congo.
>
>
>
> To me the key difference between FON and what the authors call a community
> network is the ability to actively enlarge the network. FON capitalizes on
> an existing network. It does not extend that network, it merely allows
> reciprocal access to that network by individual nodes. While this is
> already a good and useful thing, I think what many of the authors of the
> draft want to define is a user-extensible network. Below is my strawman
> definition.
>
>
>
> User-extensible network: A network in which any participant in the system
> may add link segments to the network in such a way that the new network
> 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
> extent of the network and the new extent of the network.
>
>
>
> Note that this covers a large part of the Free Network Foundation's
> Freedom 1 as posted by Roger, but not all of it.
>
>
>
> Practically I think this means that new segments of a user-extensible
> network do not involve IP address translation at the boundary of the
> network. This is important architecturally, so if someone has a good
> counter-example, please respond.
>
>
>
> For me it does not matter if the network is wired or wireless, licensed or
> unlicensed spectrum, or what technologies are used. It does not matter if
> the network has a fee structure or who administers the network. I agree
> with Steve that commercial extensible networks should be included. In Haiti
> and the parts of sub-Saharan Africa where I have lived (Benin, South Sudan,
> DRC) a commercial entity has a better chance of getting off the ground.
>
>
>
> Thanks,
>
> -rohan
>
>
>
>
>
>  Dirk Trossen
>  Principal Engineer
>  InterDigital UK, Inc.
>  Shoreditch Business Center
> 64 Great Eastern Street
>  London, EC2A 3QR
>  T: +44 20 7749 9178
>  Dirk.Trossen@InterDigital.com
>  www.InterDigital.com <http://www.interdigital.com/>
>
>
>   This e-mail is intended only for the use of the individual or entity to
> which it is addressed, and may contain information that is privileged,
> confidential and/or otherwise protected from disclosure to anyone other
> than its intended recipient. Unintended transmission shall not constitute
> waiver of any privilege or confidentiality obligation. If you received this
> communication in error, please do not review, copy or distribute it, notify
> me immediately by email, and delete the original message and any
> attachments. Unless expressly stated in this e-mail, nothing in this
> message or any attachment should be construed as a digital or electronic
> signature.
>
> _______________________________________________
> gaia mailing list
> gaia@irtf.org
> https://irtf.org/mailman/listinfo/gaia
>
>