[Ict4d] Moving Network Research group meeting to Wednesday 17 June 2:30PM ICT4D meeting room

Brian DeRenzi bderenzi at cs.uct.ac.za
Mon Jun 15 08:17:15 SAST 2015 

David,

There will be a bit of a space conflict. The codesign meeting runs 2-3p on
Wednesday and health from 330-430p.

Brian

On Sun, Jun 14, 2015 at 11:18 PM Alette Schoon <A.Schoon at ru.ac.za> wrote:

> Hi David
>
> Yes that's better for me too.
>
> Alette
>
>
> Quoting David Johnson <djohnson at csir.co.za>:
>
> > Hi all
> >
> > I only found out today that my kids are also off school on Monday 15
> > June and I want to move the network research group meeting to
> > Wednesday 17 June at the same time so I can take some leave tomorrow.
> >
> > Would this day and time work for everyone that wanted to attend?
> >
> >
> >
> > Thanks
> > David
> >
> > ___________________________
> >
> > David Johnson
> > Principal Researcher
> > Networks and Media group
> > Meraka, CSIR
> > Adjunct Senior Lecturer
> > ICT4D, Computer Science Department
> > University of Cape Town
> >
> >
> > On Wed, Jun 10, 2015 at 10:21 AM, David Johnson <djohnson at csir.co.za>
> wrote:
> >> Hi all
> >>
> >> Our next Network Research group meeting should be a pretty lively one.
> >> We are going to be discussing this very interesting email thread we've
> >> been having on
> >>
> >> - Is DTN dead
> >> - How to make applications / TCP stacks / operating systems / servers
> >> developing-world network friendly ... well that was my take on the
> >> topic of the discsussion
> >>
> >> Alette Schoon has been having problems with uploads of audio/video
> >> from hip-hop artists timing out over mobile networks which resonated
> >> with some of our current discussions on poor performance of TCP on
> >> certain operating systems ... so all this is tying together nicely
> >>
> >> Alette will be skyping in from Rhodes
> >>
> >> Any suggestions for a specific paper(s) to read - Melissa had some
> >> interesting paper suggestions from Marshini Chetty ... I vote for "Why
> >> is my internet slow?: making network speeds visible"
> >>
> >> All suggestions welcome
> >>
> >> David
> >>
> >> ___________________________
> >>
> >> David Johnson
> >> Principal Researcher
> >> Networks and Media group
> >> Meraka, CSIR
> >> Adjunct Senior Lecturer
> >> ICT4D, Computer Science Department
> >> University of Cape Town
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Alette Schoon <A.Schoon at ru.ac.za>
> >> Date: Wed, Jun 10, 2015 at 9:47 AM
> >> Subject: Re: [Ict4d] Fwd: Is DTN dead?
> >> To: Thomas Reitmaier <treitmaier at gmail.com>
> >> Cc: Melissa Densmore <melissa.r.densmore at gmail.com>, David Johnson
> >> <djohnson at csir.co.za>, Marion Walton <the.marion.walton at gmail.com>,
> >> Richard Maliwatu <richardmaliwatu at hotmail.com>
> >>
> >>
> >> Very interesting, Thomas, but I'm afraid I have no idea what it means
> >> and how this affects the upload. I somehow assumed that the internet
> >> is totally immaterial, and that as your signal bounces around in
> >> cyberspace it doesn't really matter where it goes, it's all the same
> >> for the network. Hopefully you will enlighten me on Monday.
> >>
> >>
> >> Quoting Thomas Reitmaier <treitmaier at gmail.com>:
> >>
> >>> Hi Alette,
> >>> look at the following traceroute, which prints out at the steps (hops
> in
> >>> networking speak) and time it takes in milliseconds for me to reach the
> >>> servers of kasimp3.co.za from my internet access point at home. Don't
> worry
> >>> too much about the various numbers, just focus on the domain names.
> Steps
> >>> 1-3 show my home router and how it is connected to apartment complex's
> >>> internet connection. In Steps 4 - 10, you'll notice that my apartment
> >>> complex is connected to the internet through MTN business. All pretty
> >>> standard so far. Then it gets interesting: The next hops (11) are in
> >>> Amsterdam and (12-14) in Phoenix, Arizona (USA).
> >>>
> >>> » traceroute kasimp3.co.za
> >>> traceroute to kasimp3.co.za (69.64.85.104), 64 hops max, 52 byte
> packets
> >>>  1  10.0.0.4 (10.0.0.4)  1.731 ms  1.386 ms  1.112 ms
> >>>  2  hotspot.albionnet.co.za (192.168.1.254)  4.193 ms  35.796 ms
> 15.092 ms
> >>>  3  * * *
> >>>  4  41.181.53.149 (41.181.53.149)  119.075 ms  169.156 ms  140.773 ms
> >>>  5  ipc-recieve-tb-1a.mtnbusiness.net (41.181.53.150)  86.456 ms
> 24.188
> >>> ms  16.527 ms
> >>>  6  tb-dca-2.za--qux-i.za.mtnbusiness.net (66.8.11.186)  28.924 ms
> >>>     tb-dca-2.za--qux-a.za.mtnbusiness.net (41.181.184.28)  74.133 ms
> >>> 32.935 ms
> >>>  7  compj-cpt-1.mtnns.net (196.44.18.2)  23.149 ms  24.591 ms  12.113
> ms
> >>>  8  ls-cr-2--tb-cr-1.uk-b.mtnns.net (196.44.31.113)  159.815 ms
> 196.263
> >>> ms  168.846 ms
> >>>  9  am-cr-1.nl--ls-cr-2.uk-a.mtnns.net (196.44.31.183)  182.104 ms
> 192.057
> >>> ms  260.215 ms
> >>> 10  am-tpr-1.nl--am-cr-1.nl-a.mtn.net (209.212.111.141)  194.530 ms
> >>> 172.623 ms  213.045 ms
> >>> 11  xe-4-1-0-135.edge5.amsterdam1.level3.net (212.72.41.89)  172.244
> ms
> >>> 201.675 ms  194.240 ms
> >>> 12  ae-0-11.bar2.phoenix1.level3.net (4.69.148.114)  351.307 ms
> 325.790 ms
> >>> *
> >>> 13  aph-inc.dba.bar2.phoenix1.level3.net (4.28.82.158)  355.671 ms
> 335.862
> >>> ms  516.751 ms
> >>> 14  edge1_cr1.phx.codero.com (216.55.184.98)  370.878 ms  310.218 ms
> >>> 303.125 ms
> >>> 15  69.64.66.26 (69.64.66.26)  358.165 ms  342.422 ms  339.437 ms
> >>> 16  kasimp3.co.za (69.64.85.104)  323.978 ms  395.737 ms  319.839 ms
> >>>
> >>>
> >>> So in effect your participants are uploading their stuff to, and
> >>> downloading it from, a datacenter in Arizona.
> >>>
> >>> Thomas
> >>>
> >>>
> >>>
> >>> On Tue, Jun 9, 2015 at 5:43 PM, Alette Schoon <A.Schoon at ru.ac.za>
> wrote:
> >>>
> >>>> I would love to write up something, Melissa, especially as our
> university
> >>>> now recognizes ComSci conferences in its points system. CHI or AfriCHI
> >>>> sound like the best option to get it out before anyone scoops me. Any
> >>>> chance that we could have a 'How to write a ComSci conference paper'
> >>>> workshop during my next visit in July? What do you think, Marion?
> >>>>
> >>>>
> >>>>
> >>>> Quoting Melissa Densmore <melissa.r.densmore at gmail.com>:
> >>>>
> >>>>  I love it - Alette you should write a paper on p2p pedestrian
> >>>> networks!  I
> >>>>>
> >>>>> think it's widely understood as something that happens, but there
> really
> >>>>> isn't a lot written about it, and it's important that it gets
> documented
> >>>>> as
> >>>>> a phenomenon!  It's related to some of the work on intermediaries (of
> >>>>> which
> >>>>> there is also not a lot), and as David mentioned there hasn't been a
> lot
> >>>>> of
> >>>>> work on DTNs recently.  Would you be interested in writing up
> something
> >>>>> for
> >>>>> CHI2016 (due this september) or CSCW2017 (due probably May next
> >>>>> year)?  Or
> >>>>> maybe ICTD2016 (due september?) or AfriCHI2016 (due 5 october)
> >>>>>
> >>>>> Also related - and in response to David's last email, I've been
> thinking
> >>>>> for a while about a paper on appropriate design paradigms for
> >>>>> applications
> >>>>> to be developing-world-network friendly. I sort of think of it as
> POP3 vs
> >>>>> AJAX mail.  It's not that complicated - longer timeouts, no chatty
> >>>>> mechanism, forgiving of network drops, but I'm not sure how to frame
> an
> >>>>> investigation around it.  Is the answer really to push everything to
> a
> >>>>> gateway rather than getting software developers to be aware of parts
> of
> >>>>> the
> >>>>> Internet that aren't always on and bandwidth unlimited?
> >>>>>
> >>>>> Melissa
> >>>>>
> >>>>> On Tue, Jun 9, 2015 at 4:20 PM, Thomas Reitmaier <
> treitmaier at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>  Thanks Everyone for the interesting questions and discussions!
> >>>>>>
> >>>>>>
> >>>>>> Alette, I think it might be helpful if you could give a few more
> details
> >>>>>> on the problems your participants are having. Off the top of my
> head,
> >>>>>> these
> >>>>>> questions will help us direct our discussions:
> >>>>>>
> >>>>>> What types of phones are they using? And, if possible, what
> Operating
> >>>>>> System version are they running?
> >>>>>>
> >>>>>> What cell phone network are they using (e.g. MTN, vodacom)? I'm
> assuming
> >>>>>> pre-paid? Are they purchasing data-bundles?
> >>>>>>
> >>>>>> What type of network are they connecting to (e.g. 2G, 3G)?
> >>>>>>
> >>>>>> What service are they trying to upload to?
> >>>>>>
> >>>>>> Are they uploading through an App or through the web browser?
> >>>>>>
> >>>>>> What type of content and file sizes?
> >>>>>>
> >>>>>>
> >>>>>> And please do let us know if you'd like to skype into our
> >>>>>> meeting. I'd be
> >>>>>> more than happy to set that up.
> >>>>>>
> >>>>>> Thomas
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jun 9, 2015 at 4:02 PM, David Johnson <djohnson at csir.co.za>
> >>>>>> wrote:
> >>>>>>
> >>>>>>  These are great discussions for our next network research group
> >>>>>>>
> >>>>>>> meeting - I'll schedule one for Monday 15 June now that our Masi
> trip
> >>>>>>> will be moved to Friday 19 June.
> >>>>>>>
> >>>>>>> I've been having some conversations about performance issues with
> some
> >>>>>>> of my colleagues at CSIR on other devices like XBOX that don't like
> >>>>>>> high-delay links and even androids apps that have issues ... I
> sense
> >>>>>>> there is a lot to uncover at various layers of the stack to really
> >>>>>>> understand why apps / various browser-based services perform poorly
> >>>>>>> when the network isn't perfect .. see conversation below...
> >>>>>>>
> >>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>
> >>>>>>> Hi Kobus - that's interesting. I checked my Android TCP settings
> and
> >>>>>>> the TCP receive window is fairly generous
> >>>>>>>
> >>>>>>> cat /proc/sys/net/core/rmem_max = 2,097,152 so basically 2MB ...
> this
> >>>>>>> would mean on your 5 Mbps link the receive window of your android
> >>>>>>> phone would only become a bottleneck when your delay is higher than
> >>>>>>> about 4s.
> >>>>>>>
> >>>>>>> Apps sometimes have their own  statically defined internal flow
> >>>>>>> control buffers that don't like high delay - for example you will
> >>>>>>> notice ssh often has different performance to iperf with high delay
> >>>>>>> nets - that's because its not very well tuned to high delay ..
> some of
> >>>>>>> the phone apps are probably the same. In addition servers also
> don't
> >>>>>>> like lots of hanging sockets (they consider a few seconds as a long
> >>>>>>> time) and kick you off. This was something that was really
> frustrating
> >>>>>>> in Zambia - servers would kick you off and you would have to keep
> >>>>>>> retrying a download with no differential recovery - The TCP
> connection
> >>>>>>> actually was surviving but the server threw you off.
> >>>>>>>
> >>>>>>> Of course your Microsoft box will suffer from the above + a TCP
> stack
> >>>>>>> (I assume it is the same as Windows) not well tuned to the
> occasional
> >>>>>>> high delay when the mesh is congested.
> >>>>>>>
> >>>>>>> My sense is that every home and village could do with an
> intelligent
> >>>>>>> box (connected to your 3G / ADSL ... modem) with the kind of TCP
> >>>>>>> acceleration and network optimization we see in satellite modems +
> >>>>>>> local cloud (like our VillageShare/owncloud) for sync which then
> >>>>>>> intelligently syncs to your favourite cloud service like Dropbox
> when
> >>>>>>> your net is not used + allows some level of priority on which
> folders
> >>>>>>> must sync immediately (like work docs) or can wait for periods of
> low
> >>>>>>> use (e.g. photos / videos etc.) + detecting OS queries for updates
> /
> >>>>>>> virus updates triggering a sync to the intelligent box at low usage
> >>>>>>> period (e.g. night) which then are synced to your device later.
> >>>>>>>
> >>>>>>> Something many people also don't know is the importance of
> throttling
> >>>>>>> their outbound link to around 90% of the known capacity of the
> link.
> >>>>>>> This prevents the outbound being driven to congestion when
> uploading
> >>>>>>> (e.g. dropbox sync) and dropping ACKS for web / file downloads -
> which
> >>>>>>> can have a massive impact on your incoming capacity. This is
> >>>>>>> particularly vital on ADSL modems.
> >>>>>>>
> >>>>>>> I think there is a business opportunity in an intelligent box like
> the
> >>>>>>> one above that will have a place in every home in places in the
> world
> >>>>>>> where home connections are not fibre yet and the device could also
> be
> >>>>>>> used at a rural village level in the case where connectivity is
> spread
> >>>>>>> from a shared gateway.
> >>>>>>>
> >>>>>>> There are products for windows e.g. SpeedConnect Internet
> Accelerator
> >>>>>>> - http://www.cbs-soft.com/ - but it would make much more sense to
> have
> >>>>>>> these features in a gateway
> >>>>>>> ___________________________
> >>>>>>>
> >>>>>>> David Johnson
> >>>>>>> Principal Researcher
> >>>>>>> Networks and Media group
> >>>>>>> Meraka, CSIR
> >>>>>>> Adjunct Senior Lecturer
> >>>>>>> ICT4D, Computer Science Department
> >>>>>>> University of Cape Town
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Jun 9, 2015 at 3:35 PM, Melissa Densmore
> >>>>>>> <melissa.r.densmore at gmail.com> wrote:
> >>>>>>> > which paper? the one that david sent?
> >>>>>>> >
> >>>>>>> > Actually - none of them really relate to why phones time out
> when you
> >>>>>>> do
> >>>>>>> > large uploads. Delay Tolerant Networking (DTN) for rural networks
> >>>>>>> largely
> >>>>>>> > refers to what geeks call a sneakernet approach - basically when
> >>>>>>> people
> >>>>>>> use
> >>>>>>> > SD cards and flash drives to share files instead of email,
> >>>>>>> cloud-based
> >>>>>>> file
> >>>>>>> > systems, etc.  For you - this would probably be only useful in
> the
> >>>>>>> context
> >>>>>>> > of people going to media kiosks to get movies, media and
> software.
> >>>>>>> >
> >>>>>>> > For a paper on third-party kiosks, I would read:
> >>>>>>> > Smyth, Thomas N., et al. "Where there's a will there's a way:
> mobile
> >>>>>>> media
> >>>>>>> > sharing in urban india." Proceedings of the SIGCHI
> >>>>>>> Conference on Human
> >>>>>>> > Factors in Computing Systems. ACM, 2010. (attached)
> >>>>>>> >
> >>>>>>> > For this problem of stuff timing out, you might look at Marshini
> >>>>>>> Chetty's
> >>>>>>> > work on limited bandwidth. There's a couple of explanations - the
> >>>>>>> phone
> >>>>>>> > might be low on battery and suspend the network connection.  They
> >>>>>>> might
> >>>>>>> have
> >>>>>>> > poor network connectivity and just not be able to send a large
> file
> >>>>>>> with the
> >>>>>>> > connection they have.  They could be running out of airtime in
> the
> >>>>>>> middle of
> >>>>>>> > an upload. Perhaps they are running too many applications and
> the OS
> >>>>>>> killed
> >>>>>>> > the upload process before it was finished. They could be
> uploading to
> >>>>>>> a
> >>>>>>> > website or server that is unfriendly to disconnections and
> timeouts -
> >>>>>>> that
> >>>>>>> > could be a server implementation problem or a problem more
> >>>>>>> inherent to
> >>>>>>> the
> >>>>>>> > communication protocol, such as the one David is documenting
> >>>>>>> right now
> >>>>>>> in
> >>>>>>> > his paper on why skype for windows doesn't work over satellite
> and
> >>>>>>> skype for
> >>>>>>> > unix/osx does.
> >>>>>>> >
> >>>>>>> > For Marshini's work:
> >>>>>>> > Chetty, Marshini, et al. "You're capped: understanding the
> effects of
> >>>>>>> > bandwidth caps on broadband use in the home." Proceedings of the
> >>>>>>> SIGCHI
> >>>>>>> > Conference on Human Factors in Computing Systems. ACM, 2012.
> >>>>>>> > Chetty, Marshini, et al. "Who's hogging the bandwidth: the
> >>>>>>> consequences
> >>>>>>> of
> >>>>>>> > revealing the invisible in the home." Proceedings of the SIGCHI
> >>>>>>> Conference
> >>>>>>> > on Human Factors in Computing Systems. ACM, 2010.
> >>>>>>> > Chetty, Marshini, et al. "Why is my internet slow?: making
> network
> >>>>>>> speeds
> >>>>>>> > visible." Proceedings of the SIGCHI Conference on Human Factors
> in
> >>>>>>> Computing
> >>>>>>> > Systems. ACM, 2011.
> >>>>>>> > Wyche, Susan P., et al. "Deliberate interactions: characterizing
> >>>>>>> technology
> >>>>>>> > use in Nairobi, Kenya." Proceedings of the SIGCHI Conference on
> Human
> >>>>>>> > Factors in Computing Systems. ACM, 2010.
> >>>>>>> >
> >>>>>>> > Eminently discuss-able at the next Networking meeting!
> >>>>>>> >
> >>>>>>> > Melissa
> >>>>>>> >
> >>>>>>> > On Tue, Jun 9, 2015 at 3:01 PM, Alette Schoon <A.Schoon at ru.ac.za
> >
> >>>>>>> wrote:
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >> Hi all
> >>>>>>> >>
> >>>>>>> >> I tried to read the paper, but I'm afraid I did not understand
> much
> >>>>>>> of
> >>>>>>> it.
> >>>>>>> >> Does this in any way relate to how people's phones time out
> >>>>>>> when they
> >>>>>>> try
> >>>>>>> >> and upload large audio or video phones on the mobile internet?
> >>>>>>> >> Because I'm trying to find some references that will
> >>>>>>> explain why this
> >>>>>>> >> happens among my hip hop artists in my study.
> >>>>>>> >> Any explanations will be appreciated.
> >>>>>>> >> All the best
> >>>>>>> >> Alette
> >>>>>>> >>
> >>>>>>> >> Quoting Melissa Densmore <mdensmore at cs.uct.ac.za>:
> >>>>>>> >>
> >>>>>>> >>> I would hesitate to say "dead" but you are right, there hasn't
> been
> >>>>>>> that
> >>>>>>> >>> much work done recently in the space - pretty much since Keshav
> >>>>>>> switched
> >>>>>>> >>> over to environmental sensing.  Even my Ghana Telemedicine
> Network
> >>>>>>> stuff
> >>>>>>> >>> was done back in 2008.  The main difficulty I think we
> struggled
> >>>>>>> with
> >>>>>>> was
> >>>>>>> >>> that it takes a ton of work to get a stable DTN going -
> >>>>>>> and often by
> >>>>>>> the
> >>>>>>> >>> time we got something working, mobile phones or DSL would
> >>>>>>> arrive and
> >>>>>>> >>> immediately displace our efforts.  At the same time, it's been
> 10
> >>>>>>> years
> >>>>>>> >>> and
> >>>>>>> >>> some parts of Africa are still largely unconnected.  I don't
> think
> >>>>>>> the
> >>>>>>> >>> applicability of DTN has reduced - but the number of
> researchers
> >>>>>>> looking
> >>>>>>> >>> to
> >>>>>>> >>> leverage it in isolated places has greatly reduced.  It's
> possible
> >>>>>>> that
> >>>>>>> >>> the
> >>>>>>> >>> DTN reference architecture is simply too much overhead for
> rural
> >>>>>>> >>> deployments, with no clear benefits (e.g.
> >>>>>>> interoperability, etc) for
> >>>>>>> >>> using
> >>>>>>> >>> it. Tons of people use informal DTNs (flash drives, Netflix,
> media
> >>>>>>> >>> kiosks)
> >>>>>>> >>> without using a formal network architecture worthy of a paper.
> >>>>>>> >>>
> >>>>>>> >>> Some other relevant papers:
> >>>>>>> >>> Luk, Rowena, Melissa Ho, and Paul M. Aoki. "Asynchronous remote
> >>>>>>> medical
> >>>>>>> >>> consultation for Ghana." *Proceedings of the SIGCHI conference
> on
> >>>>>>> human
> >>>>>>> >>> factors in computing systems*. ACM, 2008.
> >>>>>>> http://arxiv.org/pdf/0801.1927
> >>>>>>> >>>
> >>>>>>> >>> Ho, Melissa, and Kevin Fall. "Poster: Delay tolerant
> networking for
> >>>>>>> >>> sensor
> >>>>>>> >>> networks." *Proc. of IEEE Conference on Sensor and Ad Hoc
> >>>>>>> Communications
> >>>>>>> >>> and Networks*. 2004.
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>>
> >>>>>>>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.59.3330&rep=rep1&type=pdf
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>> Digital Study Hall was also originally a DTN-based system, most
> >>>>>>> recently
> >>>>>>> >>> presented in 2012, but focus has shifted to questions of
> >>>>>>> interaction
> >>>>>>> >>> rather
> >>>>>>> >>> than content delivery
> >>>>>>> >>> Richard Anderson, Chad Robertson, Esha Nabi, Urvashi Sahni, and
> >>>>>>> Tanuja
> >>>>>>> >>> Setia. 2012. Facilitated video instruction in low resource
> schools.
> >>>>>>> In
> >>>>>>> >>> *Proceedings
> >>>>>>> >>> of the Fifth International Conference on Information and
> >>>>>>> Communication
> >>>>>>> >>> Technologies and Development* (ICTD '12). ACM, New York, NY,
> USA,
> >>>>>>> 2-12.
> >>>>>>> >>> DOI=10.1145/2160673.2160675
> >>>>>>> http://doi.acm.org/10.1145/2160673.2160675
> >>>>>>> >>>
> >>>>>>> >>> There's also dtn stuff on SaamiNet (2009)
> >>>>>>> >>> Doria, Avri, Maria Uden, and D. Pandey. "Providing
> connectivity to
> >>>>>>> the
> >>>>>>> >>> saami nomadic community." *generations* 1.2 (2009): 3.
> >>>>>>> >>>
> >>>>>>> >>>
> >>>>>>> >>> David - I would pose this question on the gaia mailing list,
> which
> >>>>>>> >>> includes
> >>>>>>> >>> a lot of the people that originally worked on the DTN
> architecture
> >>>>>>> for
> >>>>>>> >>> both
> >>>>>>> >>> space and rural motivations.
> >>>>>>> >>>
> >>>>>>> >>> Melissa
> >>>>>>> >>>
> >>>>>>> >>> On Mon, Jun 8, 2015 at 3:56 PM, David Johnson <
> djohnson at csir.co.za>
> >>>>>>> >>> wrote:
> >>>>>>> >>>
> >>>>>>> >>>> Hi all
> >>>>>>> >>>>
> >>>>>>> >>>> One of my lectures in my Net4D honours modules is on the
> >>>>>>> use of DTN
> >>>>>>> as
> >>>>>>> >>>> a connectivity option for poorly connected areas. The
> >>>>>>> slides I have
> >>>>>>> >>>> are mostly about historical work such as DakNet (2004)
> >>>>>>> and KioskNet
> >>>>>>> >>>> (2007)
> >>>>>>> >>>>
> >>>>>>> >>>> My sense is that this research has mainly continued to have
> >>>>>>> traction
> >>>>>>> >>>> in the realm of Vehicular networks and space networks and
> that its
> >>>>>>> no
> >>>>>>> >>>> longer considered as a serious contender for rural/poorly
> >>>>>>> connected
> >>>>>>> >>>> regions ... there are some interesting new developments that
> mix
> >>>>>>> >>>> social networks and delay tolerant networks - but they seem
> mostly
> >>>>>>> >>>> like playful ideas than something to take seriously.
> >>>>>>> >>>>
> >>>>>>> >>>> Then you get weirdness like this 2014 paper from Disney on a
> DTN
> >>>>>>> >>>> solution for mico-entrepeneurs using  DTN-enabled
> >>>>>>> projects (cinemas
> >>>>>>> in
> >>>>>>> >>>> a backpack) - the example being moving content between urban
> areas
> >>>>>>> in
> >>>>>>> >>>> Pretoria and an under-served ex-homeland North of Pretoria -
> there
> >>>>>>> is
> >>>>>>> >>>> not one African researcher on the paper ... I think I
> >>>>>>> will use this
> >>>>>>> as
> >>>>>>> >>>> a prime example of what goes wrong when communities don't
> >>>>>>> participate
> >>>>>>> >>>> in the research process.
> >>>>>>> >>>>
> >>>>>>> >>>> So DTN for rural/under-serviced areas - dead?
> >>>>>>> >>>>
> >>>>>>> >>>> David Johnson
> >>>>>>> >>>> Principal Researcher
> >>>>>>> >>>> Networks and Media group
> >>>>>>> >>>> Meraka, CSIR
> >>>>>>> >>>> Adjunct Senior Lecturer
> >>>>>>> >>>> ICT4D, Computer Science Department
> >>>>>>> >>>> University of Cape Town
> >>>>>>> >>>>
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >> _______________________________________________
> >>>>>>> >> ICT4D mailing list
> >>>>>>> >> ICT4D at cs.uct.ac.za
> >>>>>>> >> http://mailman.cs.uct.ac.za/cgi-bin/mailman/listinfo/ict4d
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > --
> >>>>>>> > This message is subject to the CSIR's copyright terms and
> conditions,
> >>>>>>> e-mail
> >>>>>>> > legal notice, and implemented Open Document Format (ODF)
> standard.
> >>>>>>> > The full disclaimer details can be found at
> >>>>>>> > http://www.csir.co.za/disclaimer.html.
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > This message has been scanned for viruses and dangerous content
> by
> >>>>>>> > MailScanner,
> >>>>>>> > and is believed to be clean.
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > Please consider the environment before printing this email.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
> >> --
> >> This message is subject to the CSIR's copyright terms and conditions,
> >> e-mail legal notice, and implemented Open Document Format (ODF)
> >> standard.The full disclaimer details can be found at
> >> http://www.csir.co.za/disclaimer.html.
> >>
> >> This message has been scanned for viruses and dangerous content by
> >> MailScanner,and is believed to be clean.
> >>
> >>
> >> Please consider the environment before printing this email.
> >
> > _______________________________________________
> > ICT4D mailing list
> > ICT4D at cs.uct.ac.za
> > http://mailman.cs.uct.ac.za/cgi-bin/mailman/listinfo/ict4d
>
>
>
>
> _______________________________________________
> ICT4D mailing list
> ICT4D at cs.uct.ac.za
> http://mailman.cs.uct.ac.za/cgi-bin/mailman/listinfo/ict4d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.uct.ac.za/pipermail/ict4d/attachments/20150615/bada5bd9/attachment-0001.html>

More information about the ICT4D mailing list