[lwip-users] Re: lwip-users Digest, Vol 88, Issue 15

[Chen]

Hi Kieran,

NonAVR retransmit after a specified amount of timeout (RTO) or transmit
pool is near full. The reason you don't see any retransmission is because
the time-out was set very high on purpose.

Requiring ACK for every two TCP packets is not good for high-speed
communication:

Since the ACK can take a long time to come back if the final product is
deployed over the internet. For example, if it takes 0.5 seconds for ACK
to come back, which is shorter than RTO, then the maximum data rate is
2*1460*2, where the first 2 represents the two packets before the ACK,
1460 is the max payload, and the second 2 is max ACK within a second, and
the result is only merely 5.8KB/sec

Could you reconsider my request? (not necessary the same as NonAVR, but
something better than the current lwip)

Thanks!

Chen


> On Fri, 2010-12-10 at 15:50
> -0500, Chen wrote:
> > 
> > Both cases were created by pulling the ethernet cable on the PC to
> > demonstrate the retransmit mechanism, and Nagel is disabled in
> both
> > cases.
> > 
> > *** THERE IS NOTHING WRONG IN LWIP'S APPROACH ***, but there is room
> > to improve: If the ack comes in slower than usual, the Non-lwip
> > approach will keep the flow going and have no impact on the
> throughput
> > rate.
> > 
> > May I request such option in the future lwip?
>
> I really don't like the NonAVR version.  What will cause it to
> start
> retransmission?  It seems to have ignored the TCP retransmission
> timeout
> and is just carrying on sending new data regardless.  I would be
> against
> any change to make lwIP behave more like this.  I'm happy to see
> it
> carry on sending data until the RTO fires, but after that we must
> assume
> something is wrong and stop sending new data to retransmit old
> packets.
>
> Kieran