)]}'
{
  "commit": "6fa12c85031485dff38ce550c24f10da23b0adaa",
  "tree": "73f6cac32302ab99381f38505a5dbe930cb28e44",
  "parents": [
    "f1ecd5d9e7366609d640ff4040304ea197fbc618"
  ],
  "author": {
    "name": "Damian Lukowski",
    "email": "damian@tvk.rwth-aachen.de",
    "time": "Wed Aug 26 00:16:34 2009 +0000"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Tue Sep 01 02:45:47 2009 -0700"
  },
  "message": "Revert Backoff [v3]: Calculate TCP\u0027s connection close threshold as a time value.\n\nRFC 1122 specifies two threshold values R1 and R2 for connection timeouts,\nwhich may represent a number of allowed retransmissions or a timeout value.\nCurrently linux uses sysctl_tcp_retries{1,2} to specify the thresholds\nin number of allowed retransmissions.\n\nFor any desired threshold R2 (by means of time) one can specify tcp_retries2\n(by means of number of retransmissions) such that TCP will not time out\nearlier than R2. This is the case, because the RTO schedule follows a fixed\npattern, namely exponential backoff.\n\nHowever, the RTO behaviour is not predictable any more if RTO backoffs can be\nreverted, as it is the case in the draft\n\"Make TCP more Robust to Long Connectivity Disruptions\"\n(http://tools.ietf.org/html/draft-zimmermann-tcp-lcd).\n\nIn the worst case TCP would time out a connection after 3.2 seconds, if the\ninitial RTO equaled MIN_RTO and each backoff has been reverted.\n\nThis patch introduces a function retransmits_timed_out(N),\nwhich calculates the timeout of a TCP connection, assuming an initial\nRTO of MIN_RTO and N unsuccessful, exponentially backed-off retransmissions.\n\nWhenever timeout decisions are made by comparing the retransmission counter\nto some value N, this function can be used, instead.\n\nThe meaning of tcp_retries2 will be changed, as many more RTO retransmissions\ncan occur than the value indicates. However, it yields a timeout which is\nsimilar to the one of an unpatched, exponentially backing off TCP in the same\nscenario. As no application could rely on an RTO greater than MIN_RTO, there\nshould be no risk of a regression.\n\nSigned-off-by: Damian Lukowski \u003cdamian@tvk.rwth-aachen.de\u003e\nAcked-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": "54f212ce8aafda36ea14d8cfd973fb4bd3bffcbe",
      "old_mode": 33188,
      "old_path": "include/net/tcp.h",
      "new_id": "e5319495f15e486063c280d2a32cd5dbc48953af",
      "new_mode": 33188,
      "new_path": "include/net/tcp.h"
    },
    {
      "type": "modify",
      "old_id": "408fa4b7b9ba19d4dba2a65033a1047dd4f1debe",
      "old_mode": 33188,
      "old_path": "net/ipv4/tcp_timer.c",
      "new_id": "cdb2ca7684d4ab0821ca5c1bcc2ad72fc3aa9651",
      "new_mode": 33188,
      "new_path": "net/ipv4/tcp_timer.c"
    }
  ]
}