Revision history [back]

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have two hypothesis in mind:

1. Windows sends ut data slower, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have two hypothesis in mind:

1. Windows sends ut out the data slower, slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have two three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

Update 1: Default Congestion algorythm on mac so is cubic:MacOS is Cubic:

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

Update 1: Default Congestion algorythm on MacOS is Cubic:

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

Update 1: Default Congestion algorythm on MacOS is Cubic:

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Update 2:

If someone knows the following bullet points better, please correct me. All sources I have found, stated things sometimes differently so I tried to get it right connected.:

++++++++ open for discussions +++++++++++++++++++++ - Even Cubic uses the recovery algorithms of New Reno, it divers only in Congestion avoidance part. - an RTO causes cwnd=1 as long all outstanding data is recovered - cwnd=1 causes the receiver side to go into delayed ACK - the difference between the huge gap and the faster recovery times is SACK. A packet which causes a SACK have to send out immediately. - but due to the SACK problem on the server side, no SACK blocks can be reported anymore (See Sakes answer or the picture with the green rectangle below) ++++++++++++++++++++++++++++++++++++++++++++++++++

Original post:

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

Update 1: Default Congestion algorythm on MacOS is Cubic:

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Update 2:

If someone knows the following bullet points better, please correct me. All sources I have found, stated things sometimes differently so I tried to get it right connected.:

++++++++ open for discussions +++++++++++++++++++++ - can be discussed +++++++++++++++++++++

• Even Cubic uses the recovery algorithms of New Reno, it divers only in Congestion avoidance part. - part.
• an RTO causes cwnd=1 as long all outstanding data is recovered -
  • cwnd=1 causes the receiver side to go into delayed ACK - ACK
• the difference between the huge gap and the faster recovery times is SACK. A packet which causes a SACK have to send out immediately. -
  • but due to the SACK problem on the server side, no SACK blocks can be reported anymore (See Sakes answer or the picture with the green rectangle below)

++++++++++++++++++++++++++++++++++++++++++++++++++

Original post:

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

Update 1: Default Congestion algorythm on MacOS is Cubic:

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Update 2:

If someone knows the following bullet points better, please correct me. All sources I have found, stated things sometimes differently so I tried to get it right connected.:

++++++++ can be discussed +++++++++++++++++++++

• Even Cubic uses the recovery algorithms of New Reno, Reno, it divers only in Congestion avoidance part.congestion avoidance state.
• an RTO causes cwnd=1 cwnd=1 as long as all outstanding data is recovered
  • cwnd=1 cwnd=1 causes the receiver side to go into delayed ACK
• the difference between the huge gap and the faster recovery times is SACK. SACK. A packet which causes a SACK SACK have to send out immediately.
  • but due to the SACK SACK problem on the server side, no SACK SACK blocks can be reported anymore (See Sakes answer or the picture with the green rectangle below)

++++++++++++++++++++++++++++++++++++++++++++++++++

Original post:

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method

Update 1: Default Congestion algorythm on MacOS is Cubic:

net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 2
net.inet.tcp.cubic_sockets: 114
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0

Update 2:

If someone knows the following bullet points better, please correct me. All sources I have found, stated things sometimes differently so I tried to get it right connected.:

++++++++ can be discussed +++++++++++++++++++++

• Even Cubic uses the recovery algorithms of New Reno, it divers only in congestion avoidance state.
• an RTO causes cwnd=1 as long as all outstanding data is recovered
  • cwnd=1 causes the receiver side to go into delayed ACK
• the difference between the huge gap and the faster recovery times is SACK. A packet which causes a SACK have to send out immediately.
  • but due to the SACK problem on the server side, no SACK blocks can be reported anymore (See Sakes answer or the picture with the green rectangle below)

++++++++++++++++++++++++++++++++++++++++++++++++++

Original post:

Here comes my try of an answer: In the screenshot the followings things can be observed:

1. The server obviously supports only one SACK block
2. The client fills the gap correctly.
3. When the gap is closed the server stops advertising SACK. This is in this case an allowed behaviour, as it was not forbidden to discard packets which can´t be advertised in a SACK block
4. It can´t be told by evidence what has happened with the already transmited packets. But the server advertises them as lost packets (see second screenshot).
5. Therefor the client is still in Recovery mode and transmits the packets one by one. And obviously it is like @Syn-bit has pointed out some kind of Delayed ACK comes into play at the server side.

So why is it difefrent to Windows? I have three hypothesis in mind:

1. Windows sends out the data slower than the MacOS, so that no packet loss or packet Out of Order happens.
2. Windows does not use TCP-Timnestamping, so that the server advertises more SACK blocks.
3. Windows uses a different Recovery method