Is  peering  really  faster?  Let  the  data  speak  for  itself  

Grzegorz  Janoszka  AS43996  

Booking.com  in  numbers  

•  Booking.com  B.V.,  part  of  the  Priceline  Group  (Nasdaq:  PCLN)  

•  Each  day  more  than  700,000  room  nights  reserved  (#1  hotel  booking  website  in  the  world)  

•  Over  538000  properTes  in  207  countries  •  Website  in  42  languages  •  8000+  employees  •  135  offices  in  over  50  countries  •  33  million+  hotel  reviews  

Booking.com  peering  

•  Live:  AMS-­‐IX,  LINX,  Equinix  Ashburn,  HKIX  

•  Currently  being  delivered:  DE-­‐CIX  

•  Work  in  progress:  Equinix  Singapore  

•  2015:  5-­‐6  new  exchanges  in  EU,  3-­‐4  in  USA,  we  are  also  looking  at  other  places  

Data-­‐  vs.  opinion-­‐driven    

•  Every  change  on  the  website  is  backed  up  by  an  experiment  (A/B)  

•  “We  appreciate  that  you  believe  peering  is  faster,  but  if  it  really  is,  you  should  be  able  to  prove  it”  

•  Set  up  tools,  collect  data  before  peering  •  Peer  (the  fun  part)  •  Collect  data  again  •  Compare  

Problems,  challenges  

•  Holiday  desTnaTons  are  not  the  best  places  for  good  Internet  connecTvity  

•  Hotel  partners  have  to  use  the  admin  interface  to  provide/update  availability  

•  Bookings  via  mobile  devices  from  remote  places  

•  Our  visitors  don’t  complain,  if  Booking.com  is  slow/doesn’t  work,  they  just  try  other  website  

Tools  and  measurements  •  Latency  

•  Page  load  Tme  (both  html-­‐only  and  full-­‐content)  

•  Java  script  in  users  browsers  fetching  staTc  objects  from  mulTple  datacenters  and  reporTng  data  back  

•  4  Tier-­‐1  transits  (with  really  basic  traffic  engineering),  AMS-­‐IX  and  LINX  connecTons  

   

Results?  

Peering  is  NOT  slower…  

…or  we  haven’t  noTced  it.  

SomeTmes  it  is  indeed  faster.  

Latency  

•  Not  possible  to  check  all  peers,  so  we  focused  on  search  engines,  eyeballs,  ISP’s  and  colocaTons  

•  About  300  world-­‐wide  desTnaTons  examined  •  Small  packets  faster  by  18,2  ms  (15,2%),  big  packets  by  18,7  ms  (15,4%),  including  the  data  points  with  higher  latency  via  peering  

•  Search  engines  faster  by  12-­‐22%  (depending  on  the  service),  Googlebot  faster  by  19%  

HTML  page  load  Tme,  India  

HTML  page  load  Tme,  Thailand  

StaTc  object  download  Tme,  Indonesia  

StaTc  object  download  Tme,  Bayan,  Philippines  

3x  staTc  object  download  Tme,  Telkom,  South  Africa  

StaTc  object  download  Tme,  Ooredoo,  Qatar  

HTML  page  load  Tme,  Romania  

HTML  page  load  Tme,  Serbia  

StaTc  object  download  Tme,  Portugal  Telecom,  Portugal  

StaTc  object  download  Tme,  Switch,  Switzerland  

StaTc  object  download  Tme,  RCS  &  RDS,  Romania  

StaTc  object  download  Tme,  Vega  Telecom,  Ukraine  

Some  observaTons    

•  Shorter  AS-­‐path  may  mean  EUàUSAàASIA  •  Hairpinning  sTll  happening  in  2014  •  Paths  BookingàISPàDest  rather  rarely  improved,  so  it  is  not  that  networks  have  congested  uplinks  

•  Paths  BookingàISP1àISP2…àDest  improved  the  more  olen,  the  more  ISP’s  in  the  path  

•  The  bigger  distance,  the  more  latency  to  gain,  the  bigger  advantages  

Is  peering  really  faster?  

•  Latency  is  lower  in  most  cases  •  Bemer  page/object  load  Tme  visible  in  some  cases  

•  Mostly  stability/reliability  improvements  •  More  or  less  similar  results  could  be  possibly  achieved  by  replacing  some  transits  with  others  and  very  fine  traffic  engineering    

•  “Faster”  may  also  mean:  less  work  needed  to  achieve  bemer  performance  

QuesTons?  

Peer  with  AS43996!