[lwip-devel] [bug #32417] TCP_OVERSIZE seems to have problems with (fast-)retransmission

[Joe Eykholt]

Follow-up Comment #7, bug #32417 (project lwip):

>> 2.
> 
> Is that so? If so, that wouldn't be a bug of TCP_OVERSIZE but a general
> problem with retransmission. I.e. segments should be resent as long as they
> contain unacked data. The remote host is free to send ACKs to any amount of
> data, so that could always hit us in the middle of a segment. By adding
your
> change (TF_SEG_SENT flag), I fear we would only hide a more general
problem.

If you want to fix it differently, then that should be filed as a separate
bug.

I think it's pretty unlikely for a host to acknowledge just part of a packet
it received (i.e., it actually received a frame containing sequence 100 - 200
but decides to ack only to 150), but it certainly would be allowed.  I
suppose
it could happen if it only acks once the upper layers read the stream, and
the
application reads in smaller chunks and stops without closing.
If you modified a host to do that, and LwIP then appended past sequence 200
to
the same pbuf, I think LwIP would never retransmit it.

It's been awhile so I don't remember all of the analysis.  I did write the
description at the time, though.  If a segment is allowed 
to grow after it's sent once, it'll never get resent.  I think it's
a clean enough fix to just not append to a segment once it's been sent.

Otherwise you could do a fix to trim pbufs once they get acked.  However,
the pbuf may already be in use by the driver (for a re-send) so modifying
it once it is sent may cause problems.  I think once a pbuf is given to
a driver, it shouldn't be changed, even just to increase the length.

I agree with you on 1 and 3.

    Regards,
    Joe

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?32417>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/