delayed ack timer, slow start and LRO

delayed ack timer, slow start and LRO

[jean-pascal billaud]

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

Re: delayed ack timer, slow start and LRO

[Evgeniy Polyakov]

Hi.

On Tue, Jul 22, 2008 at 02:44:05PM -0700, jean-pascal billaud (billaud@vmware.com) wrote:
> 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 ?

You can check how your favourite driver handles lro and calls
lro_flush_all(), lro also aggregate packets upto predefined limits of
total size and numbr of 'inner' packets. It also self-destructs when
flow breaks (retransmit, pure ack and so on).

-- 
	Evgeniy Polyakov

delayed ack timer, slow start and LRO

[jean-pascal billaud]

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

delayed ack timer, slow start and LRO

[jean-pascal billaud]

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

Re: delayed ack timer, slow start and LRO

[Hagen Paul Pfeifer]

On Tue, 22 Jul 2008 15:05:26 -0700, jean-pascal billaud

<billaud@vmware.com> 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

Re: delayed ack timer, slow start and LRO

[jean-pascal billaud]

>
> On Tue, 22 Jul 2008 15:05:26 -0700, jean-pascal billaud
> <billaud@vmware.com> 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.
>
>
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


> Hagen
>
>
>
>

Re: delayed ack timer, slow start and LRO

[Ilpo Järvinen]

On Tue, 22 Jul 2008, jean-pascal billaud wrote:

Some corrections to assumptions below...

> 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.

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).

> 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).

> 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 :-)).

> 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.

> 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.


-- 
 i.

Re: delayed ack timer, slow start and LRO

[jean-pascal billaud]

> On Tue, 22 Jul 2008, jean-pascal billaud wrote:
>
> Some corrections to assumptions below...
>
>   
>> 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.
>>     
>
> 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.

>   
>> 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).
>
>   
>> 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 :-)).
>
>   
>> 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.
>
>   
>> 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.
>
>
> --
>  i.
>   
thanks for your help,

--jp