DragonFly bugs List (threaded) for 2005-03
Re: panic in TCP Limited Transmit after RTO
: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
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
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?