Subject: RE: [Tsvwg] (no subject)

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 16 Jul 2002 15:59:18 -0700

> 
>   It is pointed out in RFC 2582 that  "false fast retransmission"
> may occur because the sender could not infer which received packets
> triggered the duplicate acknowledgment without SACK
> information. However, 
> it is specified in RFC 2018 that the first SACK block reflects
> the contiguous  block of data containing the segment which 
> triggered the
> ACK unless that segment advanced the Acknowledgment Number field in
>  the header."  So, the sender may avoid  "false fast retransmission"
> problem using SACK information.  Reseting HighData  may be OK.
> 

That clause pertains to non-contiguous data arriving *above* rcv_nxt in the
sequence space.  The problem I see is that once the initial hole is plugged,
rcv_nxt advances at the receiver.  Data that triggers the dup ACKs of
concern is arriving below rcv_nxt.  So I don't think the receiver can
legally comply with the first bulleted rule in that case.  I don't think
there is a rule for that case.  My assumption is that an implementation
would then fall back to bullet 3 in RFC 2018.

Tom

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

---

From: Lili Wang <[email-masked]>
Date: Tue, 16 Jul 2002 21:58:22 -0400 (EDT)

> would then fall back to bullet 3 in RFC 2018.

If the packet arriving below rcv_nxt can generate a duplicate
acknowledgement, is it better that this acknowledgment tells the
sender which segment triggered this duplicate ACK? If the
receiver can not comply with the first rule (RFC 2018) in that case, the
sender  may detect whether it is false fast retransmission based on the 
SACK information. If the duplicate ACK is caused by retransmission
of data in the receiver queue instead of out-of-orde packet or
lost packet, the acknowledgment likely
does not carry new SACK information. Even if there is some
acknowledgment loss, it unlikely that three contiguous duplicate
ACK all carries new SACK information when duplicate ACK is
caused by retransmission of data in the receiver's queue. 

Lili

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 17 Jul 2002 14:05:04 -0400

> caused by retransmission of data in the receiver's queue. 

See RFC 2883 for more information about what to do on receipt of
packets below rcv_nxt.  There are several papers on determining the
falsehood of fast retransmits based on RFC 2883, as well.

If the loss recovery specified in this draft is forbidden until the
cumulative acknowledgement passes RecoveryPoint (Mark's and my
approach), the false fast retransmit caused by duplicate
retransmissions is a non-issue.
Ethan

-- 
Now if I wasn't such a weenie do ya think you'd still love me,
Pretendin' I'm an airplane on the living room floor?
                -- The Offspring, "I Choose"

---

From: Lili Wang <[email-masked]>
Date: Wed, 17 Jul 2002 15:02:20 -0400 (EDT)

> retransmissions is a non-issue.

 It is not clearly specified that fast recovery can not be invoked upon
receipt of three duplicate ACKs unless the
cumulative acknowledgement passes RecoveryPoint. If the loss recovery  
is forbidden in that case, what happens if there is some lost data that 
is between RecoveryPoint and HighData and HighData is above RecoveryPoint.
If the loss recovery is allowed to invoke in the second case, does the
issue about the NextSeg() discussed in the last message exist?   
 Another question is whether any lost segment below Recovery Point after
timeout will cause another timeout, since fast recovery is not allowed to
be invoked in that case.

Lili

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 17 Jul 2002 15:23:03 -0400

> is between RecoveryPoint and HighData and HighData is above RecoveryPoint.

Correct, this is not specified explicitly in revision 11.  However,
subsequent discussions (some of which were on this list, perhaps the
resolution was not) led us to add that requirement.  It should be in
-12.

> issue about the NextSeg() discussed in the last message exist?

I'm not sure I'm still clear on what the problem is ... but my
instinctive hit is that once we pass RecoveryPoint there is no reason
we cannot enter normal loss recovery as specified in the draft.  Any
misbehavior the second time around is due to a completely different
loss event.

If this algorithm 1) misbehaves on the first loss event leading to an
RTO, then 2) misbehaves on a second, separate loss event an entire
window of data later following a slow start, then I don't think we can
help your connection.

> timeout will cause another timeout, since fast recovery is not allowed to

Yes, it will.  Things are Bad at this point (you have taken an RTO on
a retransmission, and then you have more losses during slow start
within that original window of data) and we're punting.  See the above
paragraph about not being able to help your connection.  ;-)
Ethan

---

From: Lili Wang <[email-masked]>
Date: Wed, 17 Jul 2002 16:09:34 -0400 (EDT)

> misbehavior the second time around is due to a completely different

Is the reason for forbidding loss recovery before passing RecoveryPoint 
to avoid fasle fast retransmisson. If yes, the loss recovery may also
not be allowed, because retransmission of data between RecoveryPoint and
HighData may also cause false fast retransmission if HighData is above 
RecoveryPoint.
 
> paragraph about not being able to help your connection.  

However, the timeout is very costly. I guess that the reason to retransmit 
data in advance according to rule(3) in NextSeg() is to keep the ack clock
going and avoid a timeout. Without SACK, the sender choos to avoid
invoking fast recovery in some case becasue the sender has no enough
information to detect fasle fast retransmission. If we can do this with
SACK information, we may do better.  SACK is proposed to used 
to improve TCP performance. If the original window is too large and need
to cut twice, why have we to wait RTO and invoke slow start to do this?

Lili