)]}'
{
  "commit": "5fdd4baef6195a1f2960e901c8877e2105f832ca",
  "tree": "198a3f2df2bea3c5239c95957e21f3680908ddf6",
  "parents": [
    "3e9848403ad59c53b31facb30b43ca80135ae0b9"
  ],
  "author": {
    "name": "Andrei Pelinescu-Onciul",
    "email": "andrei@iptel.org",
    "time": "Sun Nov 29 00:14:02 2009 -0800"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Sun Nov 29 00:14:02 2009 -0800"
  },
  "message": "sctp: on T3_RTX retransmit all the in-flight chunks\n\nWhen retransmitting due to T3 timeout, retransmit all the\nin-flight chunks for the corresponding  transport/path, including\nchunks sent less then 1 rto ago.\nThis is the correct behaviour according to rfc4960 section 6.3.3\nE3 and\n\"Note: Any DATA chunks that were sent to the address for which the\n T3-rtx timer expired but did not fit in one MTU (rule E3 above)\n should be marked for retransmission and sent as soon as cwnd\n allows (normally, when a SACK arrives). \".\n\nThis fixes problems when more then one path is present and the T3\nretransmission of the first chunk that timeouts stops the T3 timer\nfor the initial active path, leaving all the other in-flight\nchunks waiting forever or until a new chunk is transmitted on the\nsame path and timeouts (and this will happen only if the cwnd\nallows sending new chunks, but since cwnd was dropped to MTU by\nthe timeout \u003d\u003e it will wait until the first heartbeat).\n\nExample: 10 packets in flight, sent at 0.1 s intervals on the\nprimary path. The primary path is down and the first packet\ntimeouts. The first packet is retransmitted on another path, the\nT3 timer for the primary path is stopped and cwnd is set to MTU.\nAll the other 9 in-flight packets will not be retransmitted\n(unless more new packets are sent on the primary path which depend\non cwnd allowing it, and even in this case the 9 packets will be\nretransmitted only after a new packet timeouts which even in the\nbest case would be more then RTO).\n\nThis commit reverts d0ce92910bc04e107b2f3f2048f07e94f570035d and\nalso removes the now unused transport-\u003elast_rto, introduced in\n b6157d8e03e1e780660a328f7183bcbfa4a93a19.\n\np.s  The problem is not only when multiple paths are there.  It\ncan happen in a single homed environment.  If the application\nstops sending data, it possible to have a hung association.\n\nSigned-off-by: Andrei Pelinescu-Onciul \u003candrei@iptel.org\u003e\nSigned-off-by: Vlad Yasevich \u003cvladislav.yasevich@hp.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "cd2e18778f8190569f98450842bd16458d76f0b0",
      "old_mode": 33188,
      "old_path": "include/net/sctp/structs.h",
      "new_id": "0a474568b003053686f98e27d4102d34148a8ade",
      "new_mode": 33188,
      "new_path": "include/net/sctp/structs.h"
    },
    {
      "type": "modify",
      "old_id": "c9f20e28521b069b17583e7120ea44ac0dd9eec5",
      "old_mode": 33188,
      "old_path": "net/sctp/outqueue.c",
      "new_id": "23e5e97aa6173b5684e9e930af64c5ccce590472",
      "new_mode": 33188,
      "new_path": "net/sctp/outqueue.c"
    },
    {
      "type": "modify",
      "old_id": "8674d49195561fc7ed33a5b086eb4014d80f46a7",
      "old_mode": 33188,
      "old_path": "net/sctp/sm_sideeffect.c",
      "new_id": "efa516b47e816b43bf8e6ad974f8dc5cc16d9ad9",
      "new_mode": 33188,
      "new_path": "net/sctp/sm_sideeffect.c"
    },
    {
      "type": "modify",
      "old_id": "3b141bb32faf1b954dcd0ed2b1fd77e8bc1340b6",
      "old_mode": 33188,
      "old_path": "net/sctp/transport.c",
      "new_id": "37a1184d789f7fe90408120fef731e76ed6088c4",
      "new_mode": 33188,
      "new_path": "net/sctp/transport.c"
    }
  ]
}