[tcpm] increased back-off across different retransmissions

[Marc <[e-mail]>]

Hello,

I'm reading RFC 6298, which mentions the TCP back-off algorithm. One detail
is not very clear in this RFC, or maybe I'm missing it. Hope someone can
point me in the right direction!

In our network we have a link that's sometimes congested. When that's the
case, sometimes we have a TCP connection that just has a streak of bad luck
and loses multiple packets in a row. See attachment for an example, taken
on a switch connected to the server. Unfortunately I'm not allowed to share
the PCAP.. But I think / hope the tcpdump information contains everything
needed (time, ip, port, win, seq, len, ack, sack, sle, sre..)

Client: 1.1.1.1
Server: 2.2.2.2

So some packets from Server to Client are dropped. I've marked the packets
below in attachment with P1 until P7.

Packet 1: seq 135650, len 1348, dropped
Packet 2: seq 136998, len 1348, received <-- so this one is not dropped
Packet 3: seq 138346, len 1348, dropped
Packet 4: seq 139694, len 81, dropped
Packet 5: seq 139775, len 1348, dropped
Packet 6: seq 141123, len 1348, dropped
Packet 7: seq 142471, len 1221, dropped

Then the retransmissions, marked in attachment with R1 until R5:
- Retransmission 1: 0.5 sec after dropped 'Packet 1', packet with seq
135650, len 1348 is retransmitted.
Ack <10ms. Now the ack # is 138346, higher than seq135650 + len1348 =
136998, the client is also ack'ing 'Packet 2'.

- Retransmission 2: 1.1 seconds after Retransmission 1, packet with seq
138346, len 1348 is retransmitted.
Ack <10ms, ack # 139694 (matches seq+len of Retransmission 2). This
Retransmission covers dropped 'Packet 3'

- Retransmission 3: 2.8 seconds after Retransmission 2, packet with seq
139694, len 1348 is retransmitted.
Ack <10ms, ack # 141042 (matches seq+len of Retransmission 3). Note that
this packet contains data from dropped 'Packet 4' and 'Packet 5'

- Retransmission 4: 7.1 seconds after Retransmission 3, packet with seq
141042, len 1348 is retransmitted.
Ack <10ms, ack # 142390 (matches seq+len of Retransmission 4). Note that
this packet contains data from dropped 'Packet 5' and 'Packet 6'

- Retransmission 5: 17.8 seconds after Retransmission 4, packet with seq
142390, len 1302 is retransmitted.
Ack <10ms, ack # 143692 (matches seq+len of Retransmission 5). Note that
this packet contains data from dropped 'Packet 6' and 'Packet 7'

So the back-off is increased across _different_ retransmissions, despite
the fact those retransmissions are ack'ed very quickly. Now I know there is
a chance those acks are coming from the original tranmission so the server
can't calculate a new RTT, but well.. I'm not sure if exponentially (~ x2.5
in my case actually..) increasing the timer across different ack'ed
retransmissions is the right strategy here. 10 lost packets (which isn't
pretty, I know) in my case would mean 500 seconds of waiting.

Am I right that the RFC (or Karn's algorithm) doesn't make a statement
about this particular scenario ? In that case, should it be clarified ? Or
is this such an obvious bad strategy that it's overkill to explicitly
forbid it per RFC ?

Thanks,

Marc