Re: [lwip-devel] Question about 90873d6

[Douglas]

I would be curious to learn how the tcpip congestion control and packet
loss handling is expected to work with the immediate link layer logic.
The difference might be that lwip knows if the buffer is still in the
queue and so not lost.

The issue I was exploring that appears to have resulted in this change
was the case of buffers that lwip knows are still in the link layer TX
queue. Should some of the tcpip congestion control logic kick in with
these still pending. Should the fast retransmit just be skipped in this
case. There seems little point retransmitting if lwip knows the link
layer is still trying to send the original buffer? But should other
state change to recognise the congestion?

Douglas

On 08/16/2017 01:04 AM, Joel Cunningham wrote:
> Ping!
> 
>> On Aug 9, 2017, at 3:38 PM, Joel Cunningham <address@hidden> wrote:
>>
>> In change 90873d6, the following was part of the patchset:
>>
>> -              } else if (pcb->dupacks == 3) {
>> -                /* Do fast retransmit */
>> +              } else if (pcb->dupacks >= 3) {
>> +               /* Do fast retransmit (checked via TF_INFR, not via dupacks 
>> count) */
>>
>> I think the >3 case can never get there because the if preceding checks that 
>> dupacks is > 3:
>>
>> if (pcb->dupacks > 3) {
>>  /* Inflate the congestion window, but not if it means that
>>      the value overflows. */
>>    if ((tcpwnd_size_t)(pcb->cwnd + pcb->mss) > pcb->cwnd) {
>>      pcb->cwnd = (tcpwnd_size_t)(pcb->cwnd + pcb->mss);
>>    }
>> } else if (pcb->dupacks >=3) {
>> …
>>
>> Should the original == 3 be restored?
>>
>> Joel
>> _______________________________________________
>> lwip-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-devel
> 
> 
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel
>