Subject: [tcpm] 3517 update w/ SACK-entry draft

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Sun, 17 Oct 2010 21:06:12 -0500

As Markku mentioned on the mailing list some time ago, and discussed in Anaheim, the authors of draft-ietf-tcpm-sack-recovery and RFC 3517 have discussed merging the changes that the sack-recovery draft introduces into an update to RFC 3517.  This makes a lot of sense, and simplifies the document tree we create a bit.

At this point, they're almost ready to submit the merged document, and want to confirm this path with the working group so they can figure out what to name it (draft-ietf-tcpm, or draft-lastname-tcpm).  We know that in Anaheim, Lars was concerned with the timeframe this merging might take, but there are no errata on 3517, and the sack-recovery work is felt to be complete by the authors, so the merging has good odds of completing quickly.

If there are any objections to the merged document in preparation replacing the sack-recovery working group draft (as a working group item), please bring them up in the next couple weeks.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Oct 2010 17:55:27 +0100

The only comment I would like to make is about my recent find, where TCP
SACK loss recovery implementations currently don't recover from loss of
last segement in the stream. 

It might be a good idea to add some paragraph talking about the expected
behavior so that SACK will never exhibit worst performance than NewReno?

Regards, 

Richard Scheffenegger

> -----Original Message-----
> From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] 
> [mailto:[email-masked]] 
> Sent: Sonntag, 17. Oktober 2010 22:06
> To: [email-masked]
> Subject: [tcpm] 3517 update w/ SACK-entry draft
> 
> As Markku mentioned on the mailing list some time ago, and 
> discussed in Anaheim, the authors of 
> draft-ietf-tcpm-sack-recovery and RFC 3517 have discussed 
> merging the changes that the sack-recovery draft introduces 
> into an update to RFC 3517.  This makes a lot of sense, and 
> simplifies the document tree we create a bit.
> 
> At this point, they're almost ready to submit the merged 
> document, and want to confirm this path with the working 
> group so they can figure out what to name it 
> (draft-ietf-tcpm, or draft-lastname-tcpm).  We know that in 
> Anaheim, Lars was concerned with the timeframe this merging 
> might take, but there are no errata on 3517, and the 
> sack-recovery work is felt to be complete by the authors, so 
> the merging has good odds of completing quickly.
> 
> If there are any objections to the merged document in 
> preparation replacing the sack-recovery working group draft 
> (as a working group item), please bring them up in the next 
> couple weeks.
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Ethan Blanton <[email-masked]>
Date: Mon, 18 Oct 2010 13:24:03 -0400

> last segement in the stream. 

RFC3517 SACK certainly handles this recovery, it simply requires an
RTO. This is a well-known limitation, and stems from the strict
observation of conservation of packets which is made possible by the
pipe algorithm.

Note that this behavior is described *both* in RFC 2018 (where it is
not prescriptive) and in RFC 3517 (where it is prescriptive for any
TCP implementating purporting to implement 3517), and that our present
draft of 3517bis does not change this behavior.

This situation is a corner case, and while it may have real-world
implications, I am fairly sure that we do not want to tackle it in
what is otherwise a *very* minor update.  Triggering this corner case
requires that *two* segments in the same window of data are lost, and
that they are separated by at least three segments (required to
trigger Fast Retransmit, in the absence of ER).  As an author of
3517bis, I strongly prefer to address this issue in a different
document, if at all.

I also don't think this bears on whether or not SACK-based entry to
loss recovery should be accepted as a WG document or not.  The
SACK-based entry document forwarded by Markku and Ilpo is already an
accepted WG document, and the only question is whether its new status
as 3517bis is also accepted.  Our sense (as authors) is that it was
generally accepted by the WG that 3517bis is a good path forward on
this front based on previous discussions.

Ethan

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Oct 2010 18:34:08 +0100

Ethan,

Thank you for your feedback!

I agree, that particular case is a corner case; from a conservation of
packets point of view, a full ACK (no SACK entries) below SND.MAX would
be a valid indication, IMHO - just like in NewReno. At least to address
this corner case without any undue superflous retransmits (if additional
segments are sent out, the 2nd loss in the window will eventually
recovered by the information gathered from SACK entries. This case SACK
can already cover.).

I'm already trying to prepare an I-D with this (and the lost
retransmission detection) as a "less conservative" SACK recovery method.
So I'm fine with not merging this with the pending changes of 3517bis,
and split it off into an (expirimental?) draft.

Richard Scheffenegger

> From: Ethan Blanton [mailto:[email-masked]] 
> Sent: Montag, 18. Oktober 2010 13:24
> To: Scheffenegger, Richard
> Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; [email-masked]
> Subject: Re: [tcpm] 3517 update w/ SACK-entry draft
> 
> > The only comment I would like to make is about my recent 
> find, where 
> > TCP SACK loss recovery implementations currently don't recover from 
> > loss of last segement in the stream.
> 
> RFC3517 SACK certainly handles this recovery, it simply 
> requires an RTO. This is a well-known limitation, and stems 
> from the strict observation of conservation of packets which 
> is made possible by the pipe algorithm.
> 
> Note that this behavior is described *both* in RFC 2018 
> (where it is not prescriptive) and in RFC 3517 (where it is 
> prescriptive for any TCP implementating purporting to 
> implement 3517), and that our present draft of 3517bis does 
> not change this behavior.
> 
> This situation is a corner case, and while it may have 
> real-world implications, I am fairly sure that we do not want 
> to tackle it in what is otherwise a *very* minor update.  
> Triggering this corner case requires that *two* segments in 
> the same window of data are lost, and that they are separated 
> by at least three segments (required to trigger Fast 
> Retransmit, in the absence of ER).  As an author of 3517bis, 
> I strongly prefer to address this issue in a different 
> document, if at all.
> 
> I also don't think this bears on whether or not SACK-based 
> entry to loss recovery should be accepted as a WG document or 
> not.  The SACK-based entry document forwarded by Markku and 
> Ilpo is already an accepted WG document, and the only 
> question is whether its new status as 3517bis is also 
> accepted.  Our sense (as authors) is that it was generally 
> accepted by the WG that 3517bis is a good path forward on

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 18 Oct 2010 18:14:18 -0700

The updates look good to me.

It would be better if the bis explicitly defines FlightSize or
explicitly cites the RFC5681's definition:
FLIGHT SIZE: The amount of data that has been sent but not yet
_cumulatively_ acknowledged.

Some readers (at least myself) mistakenly think that the FlightSize is
the estimated amount of
outstanding packets/bytes in the network (== the pipe var. in the RFC).

Cheers,

Yuchung

On Sun, Oct 17, 2010 at 7:06 PM, Eddy, Wesley M. (GRC-MS00)[ASRC

---

From: Matt Mathis <[email-masked]>
Date: Thu, 21 Oct 2010 11:14:19 -0700

A couple of comments:  There is an errata against 2018 about the
requirement that timeouts MUST clear the score board.   From the
errata:

"At least one OS (Linux) violates the MUST to good effect: Even when timeout
driven, it keeps old SACK data so it can avoid retransmitting data already at
the receiver. Thus even under severe bandwidth exhaustion, 100% of the data
delivered to the receiver causes forward progress and the system is not subject
to classical congestion collapse (that is, congestion collapse from
unnecessarily-retransmitted packets)."

It would be better to update section 5.1 of 3517bis to reflect this.
Note that the errata introduces several caveats and and additional
issues that need to be addressed.

Also there is another issue that should be introduced in the security
considerations section:

Traditional recovery mechanism serve to protect the Internet from
implementers who change congestion control to make it too aggressive,
because doing so tends to increase the probability of timeouts, and
often reduces overall throuthput.  This creates a strong disincentive
to deploying extra aggressive congestion control.

As recovery algorithms improve, this disincentive is reduced.  In the
limit an ideal recovery mechanism might never suffer from a timeout
except after losing an entire window of data or ACKs.  Such a recovery
algorithm might create an incentive to deploy arbitrarily aggressive
congestion control.  The algorithms presented in this document are are
believed to reduce the negative consequence of making congestion
control more aggressive than permitted by RFC 5681.

--
On other issue: would this be an appropriate time (and doc) to
introduce some other ideas from our rate halving work from  ages ago?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Sun, Oct 17, 2010 at 10:06 PM, Eddy, Wesley M. (GRC-MS00)[ASRC

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 21 Oct 2010 23:22:36 +0100

> From: Matt Mathis [mailto:[email-masked]] 
> 
> As recovery algorithms improve, this disincentive is reduced. 
>  In the limit an ideal recovery mechanism might never suffer 
> from a timeout except after losing an entire window of data 
> or ACKs.  Such a recovery algorithm might create an incentive 
> to deploy arbitrarily aggressive congestion control.  The 
> algorithms presented in this document are are believed to 
> reduce the negative consequence of making congestion control 
> more aggressive than permitted by RFC 5681.

Based on this statement, what does that mean for lost retransmission
detection, as implemented and deployed by Linux?

Would such a more ideal recovery mechanism be considered unfit for
adoption as an RFC then?

> --
> On other issue: would this be an appropriate time (and doc) 
> to introduce some other ideas from our rate halving work from 
>  ages ago?
> 

As you know, my viewpoint is, that rate halving (which is implemented in
some form in Linux and also current BSD stacks) should at least be
(informally) documented - just like lost retransmission detection
(either the way Linux is doing it, or in an idealized model).

Following up on my recent email, I'm currently investigating the special
case of loss recovery close to the end of stream, where SACK (and LRD)
fail to prevent RTOs reliably. Using SACK and timestamp information, LRD
can be made to work near optimal (no superfluous retransmits), improving
upon what Linux is already doing...

However, I would welcome any guidance the members of this group would
like to provide, before submitting my I-D on end-of-stream SACK (LRD)
behavior.

Thanks a lot,
   Richard

---

From: Ethan Blanton <[email-masked]>
Date: Fri, 22 Oct 2010 21:30:42 -0400

Hi, Matt.

> unnecessarily-retransmitted packets)."

We have discussed this, actually.  We prefer *not* to address it as
part of 3517bis for a number of reasons (my coauthors will hopefully
correct me if I misrepresent anything):

1) 3517 really only addresses the "fast recovery" portion of loss
   recovery, and has little to say about the RTO and what follows.
   The text in Section 5.1 dealing with the RTO is more or less just
   reiterating what 2018 says, and then pointing out some obvious ways
   to deal with incoming SACK data.  Note that it doesn't even specify
   precisely how a sender uses SACK data during slow start, except to
   point out that NextSeg () isn't really appropriate.

2) 3517bis is a *tiny* delta from 3517.  Look at Section 9 to see
   this.  Introducing larger changes at this point is really not
   something we want to see.  We would much rather see larger changes
   standardized separately, their kinks worked out, and then roll them
   int o 3517bis-bis if appropriate.  3517 is subtle, and we really
   feel like we got it Right in a lot of ways.  We do not want to
   introduce bugs in what is supposed to be a straightforward rev to
   improve a single, well-understood point (entry into loss recovery).

3) We do not envision RFC 3517 as being the *only* SACK algorithm out
   there.  In particular, we recognize that FACK is already in use, as
   well as variants of both 3517 and FACK.  We envision 3517 as *one*,
   sane and well-understood, way to deal with SACK information.

> issues that need to be addressed.

Things like these caveats and additional issues are precisely what I
want to avoid!

> control more aggressive than permitted by RFC 5681.

OK; I agree with your point above entirely.  We will have to think
about this with respect to 3517bis.  It is absolutely the case that
smarter loss recovery makes it more feasible to back off aggressively.
I'm not completely sure this is 3517's problem, though.

I would prefer to see this in an additional document, and I think my
coauthors would agree.

Ethan

---

From: Matt Mathis <[email-masked]>
Date: Sat, 23 Oct 2010 13:35:36 -0400

Inline

> correct me if I misrepresent anything):

Fair enough, but then please don't strengthen the incorrect language
in 2018 by citing or repeating it, especially without mentioning the
errata.  There isn't a trivial fix here, because the real problem is
that section 5.1 conflates two separate issues: what to do on a
timeout, and what to do when clearing the scoreboard due to reneging
or other events (such as timeouts as incorrectly required by 2018).
I think these should be two separate sections.   I am not  aware of
any existing description of how to handle a timeout w/o clearing the
scoreboard.

The current text clashes badly with existing, well functioning
implementations.  Insisting on keeping it will hurt the credibility of
the entire document.

> I'm not completely sure this is 3517's problem, though.

It is in scope for 3517bis, because this issue is entirely about Fast
Recovery strengthening TCP's self clock during recovery, which I
believe is an explicitly stated goal of the algorithm.

For the record, I think more aggressive CC is a good thing. Part of my
motivation for wanting this language here is to set the stage for some
future more aggressive CC algorithms.  This language explicitly
connects the future evolution in congestion control to the current
evolution in recovery algorithms.   Although as I reread it, I may
have suggested text that is just a bit too strong.

Thanks,
--MM--