)]}'
{
  "commit": "85cc391c0e4584db594bfc4005c63c07c76c5077",
  "tree": "d62f02260161ca6d0fa03986ae70a24e260d1c75",
  "parents": [
    "f577111302677e6d1448475821cc19ba8835f60e"
  ],
  "author": {
    "name": "Ilpo Järvinen",
    "email": "ilpo.jarvinen@helsinki.fi",
    "time": "Thu Nov 15 19:39:31 2007 -0800"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Mon Jan 28 14:54:03 2008 -0800"
  },
  "message": "[TCP]: non-FACK SACK follows conservative SACK loss recovery\n\nMany assumptions that are true when no reordering or other\nstrange events happen are not a part of the RFC3517. FACK\nimplementation is based on such assumptions. Previously (before\nthe rewrite) the non-FACK SACK was basically doing fast rexmit\nand then it times out all skbs when first cumulative ACK arrives,\nwhich cannot really be called SACK based recovery :-).\n\nRFC3517 SACK disables these things:\n- Per SKB timeouts \u0026 head timeout entry to recovery\n- Marking at least one skb while in recovery (RFC3517 does this\n  only for the fast retransmission but not for the other skbs\n  when cumulative ACKs arrive in the recovery)\n- Sacktag\u0027s loss detection flavors B and C (see comment before\n  tcp_sacktag_write_queue)\n\nThis does not implement the \"last resort\" rule 3 of NextSeg, which\nallows retransmissions also when not enough SACK blocks have yet\narrived above a segment for IsLost to return true [RFC3517].\n\nThe implementation differs from RFC3517 in these points:\n- Rate-halving is used instead of FlightSize / 2\n- Instead of using dupACKs to trigger the recovery, the number\n  of SACK blocks is used as FACK does with SACK blocks+holes\n  (which provides more accurate number). It seems that the\n  difference can affect negatively only if the receiver does not\n  generate SACK blocks at all even though it claimed to be\n  SACK-capable.\n- Dupthresh is not a constant one. Dynamical adjustments include\n  both holes and sacked segments (equal to what FACK has) due to\n  complexity involved in determining the number sacked blocks\n  between highest_sack and the reordered segment. Thus it\u0027s will\n  be an over-estimate.\n\nImplementation note:\n\ntcp_clean_rtx_queue doesn\u0027t need a lost_cnt tweak because head\nskb at that point cannot be SACKED_ACKED (nor would such\nsituation last for long enough to cause problems).\n\nSigned-off-by: Ilpo Järvinen \u003cilpo.jarvinen@helsinki.fi\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "26713e5d89dbe6be4a774c98d3d1374bfe006af3",
      "old_mode": 33188,
      "old_path": "net/ipv4/tcp_input.c",
      "new_id": "c0e8f2b1fa7e149585ab5b7240ab9bd96d3f44ab",
      "new_mode": 33188,
      "new_path": "net/ipv4/tcp_input.c"
    }
  ]
}