Re: [lwip-devel] Question about 90873d6

[Joel Cunningham]

> On Aug 15, 2017, at 5:20 PM, Douglas <address@hidden> wrote:
> 
> 
> 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?
> 

Sorry for the long delay on this, but I do have some thoughts.  While I agree 
that we shouldn’t unnecessarily retransmit segments when the link layer is 
full, I think having the RTO timer ticking and counting attempts (updating 
congestion control information) is important.  Not transmitting because the 
link layer is full is the same as transmitting where the link layer drops our 
packet because its full.

We want the connection timeout logic to remain in-tact and not deferred because 
of link information.  We also want the congestion control to reduce the window 
so that sending doesn’t lead to another link layer backup

Joel

> 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
>> 
> 
> 
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel