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

[" Ilpo Järvinen " <[e-mail]>]

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
> 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?

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.

> * Section 2, 5A)
> 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.

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

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.
> Do you know a better way how we can implement IsLost()? :-)

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).

> *** Minor comments
>
> * 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.
>
>
> *** Misspellings
...snip...
> %s/advertises/advertizes/g

??

Thanks for the feedback.

-- 
  i.