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

David Johnson djohnson at csir.co.za
Sun Jun 14 23:08:28 SAST 2015


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.



More information about the ICT4D mailing list