Subject: [Tsvwg] Issues with draft-blanton-dsack-use-02

From: Reiner Ludwig <[email-masked]>
Date: Fri, 11 Jul 2003 10:17:18 +0200

Hi,

Sourabh Ladha from UDEL is working with us over the summer looking into 
ways of adding Eifel to SCTP. In this context we have taken a closer look 
at the current proposals for spurious retransmit detection schemes. Here 
are some issues we found with draft-blanton-dsack-use-02 ...

A detection scheme that is intended to serve as the basis for reversing cc 
state should not declare an event a spurious retransmit if, in fact, it was 
not. This seemed to be the WG consensus after discussions about earlier 
versions of the Eifel detection algorithm. For that reason the final Eifel 
detection algorithm was extended by step (5) which is motivated in Section 
3.3 of RFC3522 ("Timeout due to loss of all ACKs"). With this extension, we 
believe that the Eifel detection algorithm is reliable, i.e., we are not 
aware of any case where it would declare an event a spurious retransmit if, 
in fact, it was not.
     [The price for that is that now we have some rare cases where spurious
      retransmits can occur that are *not* detected by Eifel.]

It seems that draft-blanton-dsack-use-02 is not that reliable since we 
think that we found the following cases where the algorithm will declare an 
event a spurious retransmit if, in fact, it was not:

1. "Timeout due to loss of all ACKs", see Section 3.3 of RFC3522.

2. Segment N is lost, the ACK for the retransmit of N is lost, and the 
second retransmit of N goes fine (the segment and the ACK for it) arrives.

3. Segment N is lost, and the retransmit of N is duplicated in the network.

Comments?

///Reiner & Sourabh 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Allman <[email-masked]>
Date: Fri, 11 Jul 2003 12:25:11 -0400

> It seems that draft-blanton-dsack-use-02 is not that reliable
> since we think that we found the following cases where the
> algorithm will declare an event a spurious retransmit if, in fact,
> it was not:
> 

Ah, yes.  So, this can be easily special cased as something like: if
everything is retransmitted and we get DSACK for everything then we
need to reduce cwnd.  (The wording needs careful crafting, but that
spirit, anyway.)

> 2. Segment N is lost, the ACK for the retransmit of N is lost, and
>    the second retransmit of N goes fine (the segment and the ACK
>    for it) arrives.
> 

I believe that long ago when we coded this algorithm in ns that
Ethan and I talked about these (and, I bet there are others).  The
document is definately missing discussion that should be there,
though.

It seems that if we cannot accept these sort of cases (pathologies,
IMO) then we cannot use DSACK for this purpose.  That is, the DSACK
signal is fundementally weak in some respects and so these sorts of
cases are inevitable.  And, note, that at least for case (3) the
document offers *some* protection.  If the sender notices a DSACK
for something that was not retransmitted then it takes the
conservative assuption that since the network is duplicating
segments the DSACK signal is not to be believed.

So, the question really is... can we accept these sorts of cases or
not?  If we cannot accept these cases then DSACK (and duplicate TSN
notification in SCTP) is pretty much useless for reverting
congestion control state.  Opinions?

My own hit is that things like 2 & 3 are pathalogical and should not
be deal breakers for DSACK-based schemes for this purpose.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 11 Jul 2003 13:02:39 -0400 (EDT)

I think I agree with Mark...

Item 1 can be handled by a special case.

Item 2 seems like a corner case to me.

Item 3... I would expect that if the network duplicates one segment, the
network will duplicate others. The sender can detect that the network is
duplicating segments, and decide to not use DSACKs.

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0

---

From: Sourabh Ladha <[email-masked]>
Date: Fri, 11 Jul 2003 14:16:41 -0400 (EDT)

> Item 2 seems like a corner case to me.

It may be..though  note that in the example we gave the ACK
for the first retransmit does not necessarily have to be lost. In general
the case can be described that the second retransmit got triggered before
the ACK for the first retransmit arrived. I wonder if SCTP
multihoming with diverse paths (retransmissions going to alternate(s))
could make this case less pathological?

> duplicating segments, and decide to not use DSACKs.

Well, in SCTP (multihomed endpoints) retransmissions SHOULD go via
alternate path. If the alternate path is duplicating packets then
the sender may never be able to realize that it is detecting losses as
spurious  retransmits (i.e. the sort of protection currently in the given
in the draft is rendered useless).

I think Mark very well noted in the mail that DSACKs alone are
weak signals and the draft notes that timestamp option may futher be used in
conjunction to refine the algorithm for network duplication scenarios.

-Sourabh

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 11 Jul 2003 14:46:20 -0400 (EDT)

> could make this case less pathological?

It may be less pathological with a multihomed SCTP association. However,
what's the loss in making a mistake on an alternate path? The cwnd of
alternate paths generally stays close to 2 MTU due to cwnd degradation (no
matter which algorithm you go with: RFC2960 or imp guide v8).

> in the draft is rendered useless).

Ok, this is true...

> conjunction to refine the algorithm for network duplication scenarios.

I agree.

~armando

0--                                                  --0

---

From: Mark Allman <[email-masked]>
Date: Sun, 13 Jul 2003 09:32:39 -0400

> It may be..though note that in the example we gave the ACK for the
> first retransmit does not necessarily have to be lost. In general
> the case can be described that the second retransmit got triggered
> before the ACK for the first retransmit arrived. I wonder if SCTP
> multihoming with diverse paths (retransmissions going to
> alternate(s)) could make this case less pathological?

If you consider the loss rate to be independent in the two
directions (or, independent on two paths for SCTP) then even a high
loss rate would yield quite low occurances of hitting the case you
mentioned.  Say the loss rate was 10% in both directions.  Now, we
have a 1% chance of falling into this situation.  That seems
pathological to me.

Now, if you broaden things to say that excessive delay imposed on
either the retransmit or the corresponding ACK can also cause us to
fall into this situation (which I agree with) that may increase the
chances.  But, I have no good idea how to quantify the chances of
that.  (My gut says that the chances of getting bit by this remain
low.) 

I'd be interested in hearing if others think that issues 2 & 3 are
showstoppers for this sort of DSACK use (reverting CC on mistakes).

Thanks!

allman

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 17 Jul 2003 16:43:26 +0200

At 18:25 11.07.2003, Mark Allman wrote:
>[...]

Since there hasn't been much traffic on this, here is my hit ...

I think that issue 3 is well taken care off in the current I-D.

But, I think that issue 2 needs to be addressed. With issue 2 we again have 
the retransmission ambiguity problem: the sender can't tell whether the 
DSACK corresponds to the 1st or the 2nd retransmit, and hence shouldn't 
make any conclusions.

So, in general dsack-use should be disabled once the second retransmit of 
the oldest outstanding segment has been sent.

///Reiner

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 17 Jul 2003 12:34:35 -0400 (EDT)

> the oldest outstanding segment has been sent.

That makes sense. I suppose this problem started the idea of using
timestamps instead?

~armando

0--                                                  --0