Subject: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01

From: "Ilpo Järvinen" <[email-masked]>
Date: Wed, 5 Aug 2009 14:12:35 +0300 (EEST)

Hi all,

We've just uploaded 01 version which is effectively the same version as
the unofficial 01a that was used as the basis of the presentation in
the Stockholm meeting. Only the following placeholders for TBD items
were added to -01 version:
- A note on Window Updates, yet another case where the improved
   algorithm has a benefit (thanks to corridor talk with Anna Brunström)
- Clarified the dupack counting rule for the case where the
   duplicate ACKs don't come "in a row"

Any feedback is more than welcome.

In the meeting it was also decided take to the mailing list the
further discussion on whether there's interest in adopting this
as a WG item?

  --
   i.

From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: New Version Notification for
     draft-jarvinen-tcpm-sack-recovery-entry-01
Date: Wed,  5 Aug 2009 02:06:14 -0700 (PDT)

A new version of I-D, draft-jarvinen-tcpm-sack-recovery-entry-01.txt has been successfuly submitted by Ilpo Jarvinen and posted to the IETF repository.

Filename:	 draft-jarvinen-tcpm-sack-recovery-entry
Revision:	 01
Title:		 Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation
Creation_date:	 2009-08-05
WG ID:		 Independent Submission
Number_of_pages: 15

Abstract:
This document describes a TCP sender algorithm to trigger loss
  recovery based on the information gathered on a SACK scoreboard
  instead of simply counting the number of arriving duplicate
  acknowledgements in the traditional way. The given algorithm is more
  robust to ACK losses, ACK reordering, missed duplicate
  acknowledgements due to delayed acknowledgements, and extra
  duplicate acknowledgements due to duplicated segments and out-of-
  window segments. The algorithm allows not only a timely initiation
  of TCP loss recovery but also reduces false fast retransmits.  It
  has a low implementation cost on top of the SACK scoreboard defined
  in RFC 3517.

The IETF Secretariat.

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 5 Aug 2009 09:48:23 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Ilpo Järvinen
>Sent: Wednesday, August 05, 2009 7:13 AM
>
>Hi all,
>

I've read this version of the document.  It looks like a pretty
reasonable thing to do to me, and the document is well-scoped
and has good discussion of the proposal itself and interactions
with other mechanisms in a TCP implementation.

I would support it as a WG item.

For better understanding of the change being made and of the
benefits, it would really help to have some time-sequence diagrams
showing the difference that this makes under the different kinds
of circumstances where it's useful (e.g. lossy ack path).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 12 Aug 2009 17:33:24 +0200

Hi all,

after carefully reading Ilpo's I-D I fully support it as a WG item.  
All in all it describes Linux
"interpretation" of RFC3517, which is IMHO a more secure way than  
simply counting
DUPACKs.

*** Comments

* I think we need a clear definition what the term DUPACK means when  
SACK is
enabled. The I-D says (page 5): We also note that the defination of a  
duplicate acknowledgement
already suggests that an incoming ACK can be considered as a duplicate  
ACK if it "contains
previously unknown SACK information" [RFC2581bis].

What does it mean exactly? Is the fact that an ACK contains new SACK  
blocks a necessary
or a sufficient property to delcare the ACK as DUPACK? Example: ACK  
with new SACK blocks,
but containing data: DUPACK or not? ACK with new SACK blocks and FIN  
bit: DUPACK or not?

* Section 2, 5A)
Why do you set HightRxt to SND.UNA?

* Section 3.1, paragraph 3:
... a TCP sender that is able to discern segment boundaries...
Example?

* Section 3.1, Note:
...the problem is not unique to this algorithm ... because of how  
IsLost() is defined.
Do you know a better way how we can implement IsLost()? :-)

*** Minor comments

* IMHO %s/RFC2581/RFC2581bis/g

* Section 1, paragraph 4 (without ADDME): Add a reference (RFC) for  
Limited Transmit.

* Section 3.2: ... case is the case ... Sounds not optimal.

*** Misspellings
%s/acknowledgements/acknowledgments/g
%s/heurestic/heuristic/g
%s/defination/definition/g
%s/approproate/appropriate/g
%s/discontiguous/discontinuous/g
%s/advertises/advertizes/g
%s/detemining/determining/g

Am 05.08.2009 um 13:12 schrieb Ilpo Järvinen:

> A new version of I-D, draft-jarvinen-tcpm-sack-recovery-entry-01.txt  
> has been successfuly submitted by Ilpo Jarvinen and posted to the  
> IETF repository.
>
> Title:		 Using TCP Selective Acknowledgement (SACK) Information to  
> Determine Duplicate Acknowledgements for Loss Recovery Initiation
> <ATT00001.txt>

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Mon, 17 Aug 2009 15:37:33 +0300 (EEST)

On Wed, 12 Aug 2009, Alexander Zimmermann wrote:

> after carefully reading Ilpo's I-D I fully support it as a WG item. All in 
> all it describes Linux
> "interpretation" of RFC3517, which is IMHO a more secure way than simply 
> counting
> DUPACKs.
>
>
> *** Comments
>
> * I think we need a clear definition what the term DUPACK means when SACK is
> already suggests that an incoming ACK can be considered as a duplicate ACK if 
> it "contains
> What does it mean exactly? Is the fact that an ACK contains new SACK blocks a 
> necessary
> or a sufficient property to delcare the ACK as DUPACK? Example: ACK with new 
> SACK blocks,
> but containing data: DUPACK or not? ACK with new SACK blocks and FIN bit: 
> DUPACK or not?

This comes quite directly from rfc2581bis, but I can understand that
it's considerably harder to understand without having duplicate 
ACK said like in RFC2581bis. I'll change it to '...as a "duplicate" ACK if 
it "contains previously unknown SACK information" [RFC2581bis]'. But even 
with that change I agree that it is useful to add a very precise 
description what should be considered as a "duplicate" ACK in the context 
of this algorithm. And that would then be made to cover also the cases 
where the ACK is in fact cumulative (either due to minor reordering or 
out-of-sync due to ACK loss).

However, I don't find problematic the examples you mention. We are not 
interested in emulating behavior of dupack counter with bug-to-bug 
compatibility. Dupack counter is an artificial metric, the real metric 
the sender is interested is the number of in-window segments that receiver 
already has buffered (and how accurately the dupack counter could estimate 
that depends on scenario). After all, we try to fix the inaccuracies in 
the dupack counter, not to duplicate them. In the cases you mentioned, we 
may miss some "duplicate" ACKs because of ACK losses but never 
overestimate them because we have not received those earlier, "real" 
duplicate ACKs. While considering all this it is good to keep in mind 
that the duplicate ACK part is just a fallback for the small segment 
sender case, the IsLost() check takes care of the other cases.

> Why do you set HightRxt to SND.UNA?

This is there to avoid implementer confusion, as RFC3517 from which we 
"borrow" the SetPipe() requires a valid HighRxt.

> ... a TCP sender that is able to discern segment boundaries...

You mean an implementation or something else?

> * Section 3.1, Note:
> ...the problem is not unique to this algorithm ... because of how IsLost() is 
> defined.

Sure, but I guess somebody might think that having to keeping track of 
segment boundaries of all segments is relatively expensive and that we 
should not be forcing all implementations to do that (please see the 
trick they used in early-rexmit to avoid keeping track of every boundary; 
though the wording there was slightly milder than what I had read into it
earlier).

> * IMHO %s/RFC2581/RFC2581bis/g

Seems sensible for the two remaining, changed.

> * Section 1, paragraph 4 (without ADDME): Add a reference (RFC) for Limited 
> Transmit.

Added.

> * Section 3.2: ... case is the case ... Sounds not optimal.
...snip...
> %s/advertises/advertizes/g

??

Thanks for the feedback.

-- 
  i.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Aug 2009 05:59:02 -0300

>   duplicate ACKs don't come "in a row"

I'm planning to review this document anytime soon. In the man time, have
you had a look at Section 9.2 of
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf ?

IIRC, that of rquiring dupacks to contain new sack information came up
while discussing Section 9.2 with Mark Allman a while ago.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1