)]}'
{
  "commit": "c2fba1112782fca82c93d3d9b1f8cd9cfe013b7f",
  "tree": "af4573b5faa2815d39bcdd850c846bfbf160eb61",
  "parents": [
    "f7c569c3f820184ad656e55ffe8ed3d074e2fbf2"
  ],
  "author": {
    "name": "QUICHE team",
    "email": "quiche-dev@google.com",
    "time": "Tue May 07 12:31:00 2019 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Tue May 07 21:03:07 2019 -0700"
  },
  "message": "Add QuicBidiTest cases for aggregation and small, frequent competing bursts.\n\nSmall, frequent spikes demonstrate a problem with GoogCC, as it doesn\u0027t compete\neffectively for bandwidth--it repeatedly yields until it\u0027s sending at about 100\nkbps.  The competing flow (10 kb every 2 seconds) should only take ~40 kbps,\nleaving ~260 kbps for the GoogCC flow.  However, the bursty nature of the\ncompetition seems to push out the Quartc/GoogCC flow.\n\nBBR has a different problem with these spikes--it seems to result in very high\nend-to-end delay (approximately 3 seconds).\n\nAggregation seems to be handled fairly well by both algorithms, but neither\nhandles it perfectly.  Both see slight reduction in throughput and slight\nincrease in average/max one-way delay.\n\nGoogCC:  http://sponge/00221ae4-e916-4277-b1c5-e2a0509d8128\nBBR:  http://sponge/18e0ab84-0005-4cf6-b2a3-b133f40d9cd8\n\ngfe-relnote: n/a (Quartc test only)\nPiperOrigin-RevId: 247069192\nChange-Id: I2cda25e404e533f89cd8a4b0a44d8b9df142431d\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "87e4cd2820709c84fc5b72d521c2d0d6c8746003",
      "old_mode": 33188,
      "old_path": "quic/quartc/test/quartc_bidi_test.cc",
      "new_id": "93dee2e72b84cf57f54efdca5c11e69c04341159",
      "new_mode": 33188,
      "new_path": "quic/quartc/test/quartc_bidi_test.cc"
    }
  ]
}