[tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) )

[Yoshifumi Nishida <[e-mail]>]

Hello Richard and all.

I've been thinking about the issue Richard brought up and I think it's
valid and worth for discussion.
I personally think this is a minor issue in RFC3517. (also in RFC3517bis)

Please allow me to explain this issue once more and please correct me
if I misunderstand something.

Let's say, we have a pair of SACK TCP sender and receiver and when
cwnd=5, sender transmits S1, S2, S3 .. S5 packets.
Now, if we lost S1, S5, segments here, we will see the following sequence.

1: When S2 S3 S4 arrives at the receiver side, the receiver sends back
dupacks with SACK info to the sender.
2: When the sender receives the 3rd dupack, it retransmits S1 and
enters loss recovery phase.
3: When S1 arrives at the receiver side, the receiver sends back a
cumulative ACK for S4.
4: When the ACK for S4 arrives, the sender process this ACK by the
following steps
    4.1: It's not greater than RecoveryPoint, so TCP cannot exit loss
recovery phase yet.
    4.2: Use update() and setpipe() and find it has only 1 outstanding segment.
    4.3: Since cwnd - pipe >= 1MSS, tcp tries to send one or more segments.
    4.4: Use NextSeg() to find the packet to be sent

Here, I think there is one minor issue in NextSeg().
When TCP checks if S5 can be sent with the rule (1) in NextSeg(), it
fails. ( because (1.b) and (1.c) return false.)
Rule (2) can be applicable "if there are available unsent data". But,
let's think about the case where there's no available unsent data.
Now, TCP is going to apply Rule (3) for S5, but again it fails (
because (1.b) returns false. )
Here, TCP cannot send any packets even though there is a chance to
send a retransmit packet.

To summarize, I think the logic in RFC3517 can stall in some
situations even though there are packets can be sent.
This might cause the lost of ack clocking and unnecessary timeouts.

I think the solution would be simple. Don't apply (1.b) to the Rule
(3) in NextSeg().
I mean, change Rule (3) in NextSeg() from

          If the conditions for rules (1) and (2) fail, but there exists
          an unSACKed sequence number 'S3' that meets the criteria for
          detecting loss given in steps (1.a) and (1.b) above
          (specifically excluding step (1.c)) then one segment of up to
          SMSS octets starting with S3 MAY be returned.

To

          If the conditions for rules (1) and (2) fail, but there exists
          an unSACKed sequence number 'S3' that meets the criteria for
          detecting loss given in steps (1.a)  above
          (specifically excluding step (1.b) and step (1.c)) then one
segment of up to
          SMSS octets starting with S3 MAY be returned.

I might need more time to think about this, but I think removing (1.b)
from (3) will not be very harmful.

Thanks,
--
Yoshifumi Nishida
[e-mail]

2010/11/15 Scheffenegger, Richard <[e-mail]>:
>
> Hi group,
>
> Following up on the discussion prior to IETF79, I submitted a draft spec to discuss TCP SACK loss recovery at end-of-stream.
>
> I believe there was also split concensus if that should be refined further to get into RFC3517bis (as it is - IMHO - a minor change under very specific circumstances to TCP SACK), or as a standalone document. I have one preference, but refrain from pursuing it actively, as there are more senior members who know better than me on these details.
>
> Thanks a lot for your time!
>
> Richard Scheffenegger
>
>
>
> A new version of I-D, draft-scheffenegger-tcpm-sack-loss-recovery-00.txt has been successfully submitted by Richard Scheffenegger and posted to the IETF repository.
>
> Filename:        draft-scheffenegger-tcpm-sack-loss-recovery
> Revision:        00
> Title:           Improving SACK-based loss recovery for TCP
> Creation_date:   2010-11-15
> WG ID:           Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This note clarifies the behavior of TCP SACK while doing loss recovery close to the end-of-stream.  This allows TCP SACK to never exhibit worse loss recovery characteristics than TCP NewReno under identical circumstances.
>
>
>
>
>
>> -----Original Message-----
>> From: Yoshifumi Nishida [mailto:[e-mail]]
>> Sent: Sonntag, 24. Oktober 2010 08:41
>> To: [e-mail]
>> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?)
>>
>> 2010/10/23 Ethan Blanton <[e-mail]>:
>>
>> > S1 ... S7 are sent.  S1, S6, and S7 are lost.  The sender
>> retransmits
>> > S1, gets a cumulative ACK for S6, retransmits S6, then gets a
>> > cumulative ACK for S7.  Should it retransmit S7?  Did the original
>> > transmission or the retransmission trigger the cum ACK for S7?
>> > Consider the case were S6 was not lost in the first place,
>> but delayed
>> > in the network for ~1RTT.  Now consider interaction with
>> timestamps,
>> > DSACK, etc. where this potentially *can* be disambiguated.
>>
>> In my feeling, this depends on the pipe size.
>> if cwnd - pipe >= 1 SMSS, we can send at least 1 packet.
>> In this example, S8 will be sent. ( rule (2) in NextSeg()
>> will be applied) If S8 can arrive at the receiver
>> successfully, the sender can get good estimation for lost
>> packets by the ACK for S8. Then, it can retransmit proper packets.
>>
>> However, as Richard already pointed out, if this is the end
>> of transmission, there is no S8.
>> In this case, I think retransmitting S7 will not be harmful so much.
>>
>> If this is not the end of transmission (e.g. application
>> stall), I'm not very sure whether we should retransmit a packet.
>>
>> Thanks,
>> --
>> Yoshifumi Nishida
>> [e-mail]
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>