#6162 HIGH Never A: Use a higher TTL for hostname like records

[Zarro Boogs per Child]

#6162: Use a higher TTL for hostname like records
-----------------------------+----------------------------------------------
 Reporter:  sjoerd           |       Owner:  Collabora     
     Type:  defect           |      Status:  new           
 Priority:  high             |   Milestone:  Never Assigned
Component:  telepathy-salut  |     Version:                
 Keywords:                   |    Verified:  0             
 Blocking:                   |   Blockedby:                
-----------------------------+----------------------------------------------
 In the mongolian deployment the network seems to melt, because all mdns
 traffic is repeated by all nodes on the mesh. We unfortunately can't
 easily fix the mesh, but we can try to tune down avahi a bit.

 Seeing the wireless dumps dwmw2 gave me, most of the mdns queries are for
 A records. These have a mdns TTL of 2 minutes. Avahi will do a new query
 for each record when 80% of the TTL has elapsed (with a 2% jitter).. So
 every +/- 96 seconds a new query is started for each record and repeated
 various times if there was no anwser (at 85, 90 and 95% to be precise).
 (Do note that queries won't be actually send out if another node sent a
 similar question, but this doesn't help much if a lot of traffic is
 dropped)

 If we up the TTL to 10 minutes, then the queries for refresh will only be
 done every +/- 8 minutes and potential resends are spread out furthertoo .
 Which should reduce the network load significantly. The obvious downside
 being that nodes that left ungracefully aren't detected as quickly as
 before.

 The patch for this is a oneliner (attached).. The big question is imho how
 to get this onto the builds for mongolia asap. The avahi in joyride is
 quite a bit newer then what's in ship.2, so i'm a bit unsure about what
 the right procedure is here.

 Also the change in #5501 might be helpfull, all unnecessary disregarded
 records will result in extra traffic in the long run as all relevant
 records need to be re-resolved. Which because of the key in the TXT there
 is quite big.


 And while this probably doesn't need repeating once again.. This situation
 really shows how important it is to get proper multicast routing into the
 mesh implementation. On a pure mesh (thus without mesh portals around),
 multicast will dominate the traffic. Not just because of mdns, but mostly
 because our communication protol uses multicast.

-- 
Ticket URL: <http://dev.laptop.org/ticket/6162>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system