)]}'
{
  "commit": "ddf1af6fa00e772fdb67a7d22cb83fac2b8968a8",
  "tree": "0ef97572fcecf0c7e2d6a6c3b06102213a312b87",
  "parents": [
    "31ba0c10723e9eba378f96de1d1a9426129949e1"
  ],
  "author": {
    "name": "Yuchung Cheng",
    "email": "ycheng@google.com",
    "time": "Tue Feb 02 10:33:06 2016 -0800"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Sun Feb 07 14:09:51 2016 -0500"
  },
  "message": "tcp: new delivery accounting\n\nThis patch changes the accounting of how many packets are\nnewly acked or sacked when the sender receives an ACK.\n\nThe current approach basically computes\n\n   newly_acked_sacked \u003d (prior_packets - prior_sacked) -\n                        (tp-\u003epackets_out - tp-\u003esacked_out)\n\n   where prior_packets and prior_sacked out are snapshot\n   at the beginning of the ACK processing.\n\nThe new approach tracks the delivery information via a new\nTCP state variable \"delivered\" which monotically increases\nas new packets are delivered in order or out-of-order.\n\nThe reason for this change is that the current approach is\nbrittle that produces negative or inaccurate estimate.\n\n   1) For non-SACK connections, an ACK that advances the SND.UNA\n   could reset the DUPACK counters (tp-\u003esacked_out) in\n   tcp_process_loss() or tcp_fastretrans_alert(). This inflates\n   the inflight suddenly and causes under-estimate or even\n   negative estimate. Here is a real example:\n\n                   before   after (processing ACK)\n   packets_out     75       73\n   sacked_out      23        0\n   ca state        Loss     Open\n\n   The old approach computes (75-23) - (73 - 0) \u003d -21 delivered\n   while the new approach computes 1 delivered since it\n   considers the 2nd-24th packets are delivered OOO.\n\n   2) MSS change would re-count packets_out and sacked_out so\n   the estimate is in-accurate and can even become negative.\n   E.g., the inflight is doubled when MSS is halved.\n\n   3) Spurious retransmission signaled by DSACK is not accounted\n\nThe new approach is simpler and more robust. For SACK connections,\ntp-\u003edelivered increments as packets are being acked or sacked in\nSACK and ACK processing.\n\nFor non-sack connections, it\u0027s done in tcp_remove_reno_sacks() and\ntcp_add_reno_sack(). When an ACK advances the SND.UNA, tp-\u003edelivered\nis incremented by the number of packets ACKed (less the current\nnumber of DUPACKs received plus one packet hole).  Upon receiving\na DUPACK, tp-\u003edelivered is incremented assuming one out-of-order\npacket is delivered.\n\nUpon receiving a DSACK, tp-\u003edelivered is incremtened assuming one\nretransmission is delivered in tcp_sacktag_write_queue().\n\nSigned-off-by: Yuchung Cheng \u003cycheng@google.com\u003e\nSigned-off-by: Neal Cardwell \u003cncardwell@google.com\u003e\nSigned-off-by: Eric Dumazet \u003cncardwell@google.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b386361ba3e87226c329924bc1992252fcf0b9d6",
      "old_mode": 33188,
      "old_path": "include/linux/tcp.h",
      "new_id": "d909feeeaea25f437505734f24129c54d86719de",
      "new_mode": 33188,
      "new_path": "include/linux/tcp.h"
    },
    {
      "type": "modify",
      "old_id": "dc810df53e90b67c9c1fcf20c963c22111092a8a",
      "old_mode": 33188,
      "old_path": "net/ipv4/tcp_input.c",
      "new_id": "2d690b3f0a7b2f2296188de9b79076ded46627a9",
      "new_mode": 33188,
      "new_path": "net/ipv4/tcp_input.c"
    }
  ]
}