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

[Thomas Reitmaier]

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

-----Original Message-----
From: "Brian DeRenzi" <bderenzi at cs.uct.ac.za>
Sent: ‎6/‎15/‎2015 8:17 AM
To: "Alette Schoon" <A.Schoon at ru.ac.za>; "ict4d at cs.uct.ac.za" <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
>>>>>>> - <a href=

[The entire original message is not included.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.uct.ac.za/pipermail/ict4d/attachments/20150615/bdf41646/attachment-0001.html>