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

Mon Jun 15 18:03:01 SAST 2015

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
>