delayed ack timer, slow start and LRO
Subsystems (2)
Hi,
I have a question related to the interaction between the delayed ack timer, slow start and LRO.
If the sender is doing a slow start, it is going to send one packet. The receiver's delayed ack timer is going to
kick in and when it expires it will send a ack.
Then the sender is going to send 2 packets now. LRO will aggregates them and the receiver's delayed ack timer is going
to kick in, hoping another packet will arrives which is not going to be the case. When the timer expires it is going to
send a ack.
The sender is now going to send 4 packets. LRO will aggregate them and the receiver's delayed ack timer is going to
kick in, hoping another packet will arrives which is not going to be the case. When the timer expires it is going to
send a ack.
The sender is now going to send ... So I am under the impression that due to the fact that LRO is aggregating packets,
the delayed ack timer will kick in every single time.
So how is this fixed in linux ? I believe that ABC implementation will fix this issue even if I am not completely sure
about that ?
Also as LRO adds some latency, it seems possible to me that the sender retransmission timer will expires before the
delayed ack timer expires. In this case, how is this gonna work ? Is it possible that the sender will stay stuck in
its slow start trying to retransmit endlessly the same n packets ?
Can anyone help on that ?
thanks,
--jp
On Tue, 22 Jul 2008 15:05:26 -0700, jean-pascal billaud
Quoted 3 lines · <[email protected]> wrote:
I have a question related to the interaction between the delayed ack
timer, slow start and LRO.
AFAIK, delayed ACKs are disabled in slow start phase.
Hagen
Quoted 5 lines
On Tue, 22 Jul 2008 15:05:26 -0700, jean-pascal billaud <[email protected]> wrote:
Quoted 7 lines
Quoted 3 lines
I have a question related to the interaction between the delayed ack timer, slow start and LRO.
AFAIK, delayed ACKs are disabled in slow start phase.
Probably a dummy question but how the receiver can know when the slow start phase is done, as slow start is done by the sender.
thanks for your help,
--jp
Quoted 5 lines
Hagen
On Tue, 22 Jul 2008, jean-pascal billaud wrote:
Some corrections to assumptions below...
Quoted 7 lines
I have a question related to the interaction between the delayed ack timer, slow start and LRO.
If the sender is doing a slow start, it is going to send one packet. The receiver's delayed ack timer is going to
kick in and when it expires it will send a ack.
Quoted 5 lines
Then the sender is going to send 2 packets now. LRO will aggregates them and the receiver's delayed ack timer is going
to kick in, hoping another packet will arrives which is not going to be the case. When the timer expires it is going to
send a ack.
What makes you think so? ...please see conditions in __tcp_ack_snd_check(). ...and like somebody else mentioned, there are quickacks in the picture as well (aka. Delayed ACK After Slow-Start, DAASS).
Quoted 5 lines
The sender is now going to send 4 packets. LRO will aggregate them and the receiver's delayed ack timer is going to
kick in, hoping another packet will arrives which is not going to be the case. When the timer expires it is going to
send a ack.
Likewise, though in here tcp_max_burst would prevent as large growth as without lro (in other slow-starts than the initial one).
Quoted 7 lines
The sender is now going to send ... So I am under the impression that due to the fact that LRO is aggregating packets,
the delayed ack timer will kick in every single time.So how is this fixed in linux ? I believe that ABC implementation will fix this issue even if I am not completely sure
about that ?
ABC is nowadays disable by default because it was found to annoy small segment sending folks enough for them to periodically to come up complaining with that "discovery" on netdev... :-) ...ABC is not that necessary in Linux anyway because Linux' segment based counting is not vulnerable to same kind of problems that byte-based approach would be. Faster window growth during slow-start could be done without ABC though nobody has yet stepped in to do that (though I just got an idea while writing how to do that cleanly :-)).
Quoted 3 lines
Also as LRO adds some latency, it seems possible to me that the sender retransmission timer will expires before the
delayed ack timer expires.
In theory yes, but in reality that shouldn't happen since RTT is calculated so that it would include the delayed ACK delays.
Quoted 3 lines
In this case, how is this gonna work ? Is it
possible that the sender will stay stuck in
its slow start trying to retransmit endlessly the same n packets ?
It wouldn't anyway, because receiver would ACK out-of-order (a duplicate below window) segments immediately. ...And we would resort FRTO in between too and RTO would be declared spurious and TCP would continue sending new data.
Signature · 1 line
i.
Quoted 20 lines · jean-pascal billaud
Some corrections to assumptions below...
Quoted 7 lines
I have a question related to the interaction between the delayed ack timer, slow start and LRO.
If the sender is doing a slow start, it is going to send one packet. The receiver's delayed ack timer is going to
kick in and when it expires it will send a ack.Quoted 6 lines
Then the sender is going to send 2 packets now. LRO will aggregates them and the receiver's delayed ack timer is going
to kick in, hoping another packet will arrives which is not going to be the case. When the timer expires it is going to
send a ack.
Quoted 5 lines
What makes you think so? ...please see conditions in
__tcp_ack_snd_check(). ...and like somebody else mentioned, there are quickacks in the picture as well (aka. Delayed ACK After Slow-Start, DAASS).
Ok. I found the quickack mode bound by TCP_MAX_QUICKACKS, so by knowing that my assumptions are not correct anymore. I am going to check if BSD has the same behavior.
Quoted 45 lines
Quoted 7 lines
The sender is now going to send 4 packets. LRO will aggregate them and the receiver's delayed ack timer is going to
kick in, hoping another packet will arrives which is not going to be the case. When the timer expires it is going to
send a ack.Likewise, though in here
tcp_max_burstwould prevent as large growth as without lro (in other slow-starts than the initial one).Quoted 8 lines
The sender is now going to send ... So I am under the impression that due to the fact that LRO is aggregating packets,
the delayed ack timer will kick in every single time.So how is this fixed in linux ? I believe that ABC implementation will fix this issue even if I am not completely sure
about that ?ABC is nowadays disable by default because it was found to annoy small segment sending folks enough for them to periodically to come up complaining with that "discovery" on netdev... :-) ...ABC is not that necessary in Linux anyway because Linux' segment based counting is not vulnerable to same kind of problems that byte-based approach would be. Faster window growth during slow-start could be done without ABC though nobody has yet stepped in to do that (though I just got an idea while writing how to do that cleanly :-)).
Quoted 4 lines
Also as LRO adds some latency, it seems possible to me that the sender retransmission timer will expires before the
delayed ack timer expires.In theory yes, but in reality that shouldn't happen since RTT is calculated so that it would include the delayed ACK delays.
Quoted 4 lines
In this case, how is this gonna work ? Is it
possible that the sender will stay stuck in
its slow start trying to retransmit endlessly the same n packets ?
Quoted 9 lines
It wouldn't anyway, because receiver would ACK out-of-order (a duplicate below window) segments immediately. ...And we would resort FRTO in between too and RTO would be declared spurious and TCP would continue sending new data.
--
i.
thanks for your help,
--jp