Subject: Re: [Tsvwg] T3 cannot timeout???

From: [email-masked]
Date: Fri, 26 Apr 2002 14:01:35 -0400

All,
Thanks for the prompt replies.  We tried your suggestion, and had somewhat 
better success, but....
OK, so we are now sending SACKs to the PRIMARY whenever they are bundled 
with DATA.  Well, when the PRIMARY cable is pulled, both sides start 
RTXing to dest 2. But, since we have heavy traffic, the SACKs for the 
RTX'd data is bundled with new data, and sent over the (dysfunctional) 
PRIMARY.  Whoops, the RTX'd data doesn't get ACK'd until each side 
declares the PRIMARY dead and switches to the 2nd dest.
I'm going to try instead to bundle SACKs with DATA ONLY if the 
destinations are the same, so that data RTX'd on non-primaries will have 
SACKs sent on the same non-primary, and we won't be able to bundle in this 
case.
Any thoughts on this?

DaveS.

"Brian F. G. Bidulock" <[email-masked]>
04/26/2002 11:11 AM
Please respond to bidulock

        To:     Randall Stewart <[email-masked]>
        cc:     [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked]
        Subject:        Re: [Tsvwg] T3 cannot timeout???

Randall,

On Fri, 26 Apr 2002, Randall Stewart wrote:

> [email-masked] wrote:
> > 
> >         Hi Dave!
> > 
> >         I must confess that I don't really follow you, but let's 
try...
> > 
> > > Hello,
> > > We've found a Here's a case we found, hopefully someone can help!
> > >
> > > 2 peers (A and B) with 2 destinations (1 and 2) each, both
> > > using the same
> > > path as the 'primary'.
> > 
> >         Let me check if I know what you are saying here... Peer A uses 
IPa1 and IPa2, and peer B uses IPb1 and IPb2... So, you mean that A's 
primary address is IPb1 and uses IPa1 as the source address, and peer B 
uses IPa1 as primary and IPb1 as the source address for those datagrams, 
right?
> > 
> > > Primary ethernet goes down.
> > 
> >         Which one? IPb1?
> > 
> > > Side A detects this, and switches to destination 2.
> > 
> >         Ok, now A is using IPb2...
> > 
> > > Side B's T3 timer hasn't yet expired, but starts receiving
> > > data from A on
> > 
> >         Ok... I think I understand you now that I read it again... You 
mean that there are two independent Ethernet networks... So IPa1 and IPb1 
are in the same network, and IPa2 and IPb2 are in another network. Am I 
right?
> > 
> > > 2.  B sends SACK on 2nd path (since that's where it got the data), 
and
> > > since it also has data to send, it bundles DATA chunks with the 
SACK.
> > 
> >         I don't think this is the right thing to do... You always use 
the primary address until it is down... I would most probably do it in the 
other way: sending SACKs bundled with the DATA chunks sent to the primary 
address...
> > 
> 
> I agree with Ivan here.. You BUNDLE and send the SACK to
> the PRIMARY address when you are putting it with DATA. NOT to
> where it came from...
> 
> 
> R

That's what I do too.  Works for me.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 26 Apr 2002 13:36:43 -0500

Dave:

Another little trick that you may not be doing 
when you recieve duplicate data chunks .. you retransmit to
alternate destinations for the SACK. 

This in some cases means you WON'T bundle the SACK's and the
DATA.. but thats ok.

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 Apr 2002 14:03:25 -0500

Randall,

Again, that's what I do too. (And it is stated in the RFC.) The
first retrans in Dave's scenario results in dups which are used
as an indication that SACKs aren't being received and should be
sent to an alternate destination.

--brian