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

[David Johnson]

These are some good papers (thanks Melissa - didn't know you were a go
Author with Wyche on one of my favourite papers) to read some informal
media sharing techniques in india and on how user behaviour changes
when Internet availability is limited and costly. The Chetty papers
are interesting on what's happening to your bandwidth in the Internet
in your home - but I feel like we can use some of the concepts and
then reapply this in African setting.

we won't have time to go through these papers today - but perhaps lets
pick one or two to discuss in more details next time.

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 17, 2015 at 1:31 PM, David Johnson <djohnson at csir.co.za> wrote:
> I'm trying to pull together hundreds of conversation threads from the
> past few weeks on poor network performance and DTN etc. And wanted to
> come up with a sort of Douglas Adams the answer to life the universe
> and everything view of this - here's a rough attempt and something we
> can mull over in our meeting today as we talk through things
>
> For our target areas communities we categorize various types of
> Connection options (some of thee being the very ones we are trialling
> ourselves), behaviours, issues and options
>
> For all possible connections for a region define these parameters over
> 24 hour or even weekday/weekend cycle
>
> Type of connection can be: (1) always on by design (Satellite, 3G,
> ADSL WiFi), (2) DTN by design with two categories: (a) DTN using a
> data mule using regular route, (b) DTN using a epidemic network with
> viral like transmission of data through network. Obviously DTN can
> also come into the picture if (1) is hit by frequency power failures
> or other causes of disconnects (3) peer-to-peer file sharing e.g.
> Bluetooth over phone (4) Central data hub (commercial or free) to drop
> /store and retrieve media
>
> Parameters that need to be known over 24 hour /cycle (in order to know
> best time of use)
>
> (1) Bandwidth, (2) on/off duty cycle due to power instability, (3)
> delay (in region of ms / seconds for always on and in region of
> minutes/hours/days for DTN using statistical averages) , packet loss,
> price (can vary to encourage usage during low usage periods), cap (per
> day or per month e.g. Tshwane wireless 300MB free per day),
>
>
> Specific networking anomalies when specific devices, applications,
> servers encounter networks these parameters: OS-specific issues due to
> TCP type or TCP default receive windows e.g. Windows uploads perform
> poorly with high bandwidth-delay product, (2) Software with its own
> own  statically defined internal flow control buffers that frequently
> disconnects in the presence of high delay / packet loss, (3) servers
> that kick you off in the presence of high delay
>
> Deliberate networking need  (user) : e.g. could be Low-delay,
> low-cost, zero-cost, urgent delivery or combination of thee
>
> Non-deliberate networking need (device) : Virus updates, OS updates
> etc. which should usually prioritize low-cost but may be urgent
>
> For our specific scenario there will often be multiple connection
> types available (e.g. some capped free wifi, a 3G network, a data mule
> that visits an urban area. Based on the deliberate or non-deliberate
> networking need a network will be chosen to meets this need. e.g. need
> to share a large video with someone in my local community, need to
> upload a youtube video … could we create a system that can automate
> this process to some degree or is this over designing the problem and
> we rather inform users of options and rely on their savviness to make
> the right choice.
>
> Cheers
> David
> ___________________________
>
> David Johnson
> Principal Researcher
> Networks and Media group
> Meraka, CSIR
> Adjunct Senior Lecturer
> ICT4D, Computer Science Department
> University of Cape Town
>
>
> On Mon, Jun 15, 2015 at 6:03 PM, David Johnson <djohnson at csir.co.za> wrote:
>> Ok great - lets make it 2:00PM Wednesday then just to be safe
>>
>> David
>> ___________________________
>>
>> David Johnson
>> Principal Researcher
>> Networks and Media group
>> Meraka, CSIR
>> Adjunct Senior Lecturer
>> ICT4D, Computer Science Department
>> University of Cape Town
>>
>>
>> On Mon, Jun 15, 2015 at 8:28 AM, Brian DeRenzi <bderenzi at cs.uct.ac.za> wrote:
>>> Ok, great, I stand corrected. Thanks guys.
>>>
>>> Brian
>>>
>>> On Mon, Jun 15, 2015 at 8:26 AM Thomas Reitmaier <treitmaier at gmail.com>
>>> wrote:
>>>>
>>>> Hi networking group,
>>>> The co design group has switched to a fortnightly schedule for the vac, so
>>>> it won't be meeting this week. So as long as we don't run over an hour,
>>>> there won't be any conflict.
>>>>
>>>> Thomas
>>>> ________________________________
>>>> From: Brian DeRenzi
>>>> Sent: ‎6/‎15/‎2015 8:17 AM
>>>> To: Alette Schoon; ict4d at cs.uct.ac.za
>>>> Subject: Re: [Ict4d] Moving Network Research group meeting to Wednesday
>>>> 17June 2:30PM ICT4D meeting room
>>>>
>>>> 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
>>>>> >>>>>>> -
>>>>
>>>>
>>>> [The entire original message is not included.]
>>>
>>>
>>> --
>>> 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
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smyth-mediasharing.pdf
Type: application/pdf
Size: 439338 bytes
Desc: not available
URL: <http://mailman.cs.uct.ac.za/pipermail/ict4d/attachments/20150617/bbcdb5d2/attachment-0004.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wyche_deliberate_interactions.pdf
Type: application/pdf
Size: 646811 bytes
Desc: not available
URL: <http://mailman.cs.uct.ac.za/pipermail/ict4d/attachments/20150617/bbcdb5d2/attachment-0005.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chetty1.pdf
Type: application/pdf
Size: 616583 bytes
Desc: not available
URL: <http://mailman.cs.uct.ac.za/pipermail/ict4d/attachments/20150617/bbcdb5d2/attachment-0006.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chetty2.pdf
Type: application/pdf
Size: 627266 bytes
Desc: not available
URL: <http://mailman.cs.uct.ac.za/pipermail/ict4d/attachments/20150617/bbcdb5d2/attachment-0007.pdf>