Re: panic in TCP Limited Transmit after RTO

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:My previous patch fixes the burst. It sends only one data segment
:starting at snd_nxt on each Limited Transmit.  The reason why it
:starts to send data starting at snd_nxt is that DragonFlyBSD does so.
:I just followed its behavior.
:
:If Limited Transmit requires to send new data starting at snd_max,
:(I just re-read RFC3042, and it says so), the attached patch
:does it.  It simply tweaks snd_nxt during calling tcp_output().
:
:I made graphs of the behaviors of your second patch and my second
:patch at http://www.dd.iij4u.or.jp/~demizu/dragonfly/0315/
:
:The first graph shows the behavior of your second patch.
:(The red line represents seq, while the green line represents ack)
:After an RTO, on limited transmit, it sends bursty data, then enters
:recovery phase.  In recovery mode, it sends both new data and lost data.
:
:The second graph shows the behavior of my second (attached) patch.
:On each limited transmit, it just sends one data segment starting
:at snd_max.

    Looking at the second graph it appears to be sending data at both
    snd_nxt and snd_max, just like Jeff's, but the difference being
    that Jeff's was also sending bursts from snd_nxt while yours does
    not.  Am I correctly identifying the difference between the two
    patches?

    I am not an expert on the RFC's like you guys are, but it is pretty
    clear from the graphs that the bursted data being sent by Jeff's second
    patch is just wasting bandwidth (at least in this test), since the
    burst size is too big for the target to handle.  But, at the same time,
    the second patch seems to be sending too little data at snd_nxt when,
    clearly, it could be sending more.

    From my visual inspection wouldn't it be better to still send a burst
    of old (snd_nxt based) data while simultaniously sending just one
    segment at snd_max via limited_transmit?  Obviously the burst should not
    be as long as the one Jeff's patch produces, but sending just one packet
    at snd_nxt also seems wrong when, clearly, the link is able to handle
    more then one-packet bursts and snd_nxt.

    This is a combination of cases that would only occur when the
    connection has both SACK AND limited_transmit capabilities and perhaps
    the RFC is not considering this combination of cases properly?

						-Matt