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

[Alexander Zimmermann <[e-mail]>]

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:

> 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 <[e-mail]>
> To: [e-mail]
> Cc: [e-mail]
> 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.
> <ATT00001.txt>

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//