Re: [tcpm] end-of-stream loss recovery (TCP SACK)

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:nishida@sfc.wide.ad.jp] 
> Sent: Sonntag, 24. Oktober 2010 08:41
> To: tcpm@ietf.org
> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?)
> 
> 2010/10/23 Ethan Blanton <eblanton@cs.ohiou.edu>:
> 
> > 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
> nishida@sfc.wide.ad.jp
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 