Subject: Question: Which address to choose...

From: Andreas Jungmaier <[email-masked]>
Date: Tue, 7 Oct 2003 14:42:04 +0200

Hi all,

I just stumbled across a (probably stupid) little question, the answer
for which I could not find in the RFC 2960 (or imp guide which I scanned
for this topic) :

Suppose, endpoint A and endpoint B are both dual-homed.
The primary path for both is A1<->B1, secondary path is A2<->B2.

Now, A has received the last valid data from B on the secondary path,
has started a SACK-timer, and its user wants to send NEW data over 
the primary path.

The outgoing SCTP packet carries a SACK along with the new data.

Which rule gets precedence:
- - send all new data over the primary path (initial transmission).
- - send the SACK back to the address where the last data came from

Where does it say so in the specs ?

Best regards,
Andreas

- -- 
Dipl.-Ing. Andreas Jungmaier              
Computer Networking Technology Group     
University of Duisburg-Essen                       
http://www.exp-math.uni-essen.de/~ajung   
PGP Key-ID: D382 4AC0             

PGP Key-Fingerprint: 228C 7C2C 3381 2DD4  9998 2812 5C0B 0B04  D382 4AC0

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 07 Oct 2003 08:22:41 -0500

Andreas Jungmaier wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi all,
>

Andreas:

I don't think it is specific in the spec. If you look at the rule:

"- - send the SACK back to the address where the last data came from"

Its not really quite stated that way... its
 
  An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
   etc.) to the same destination transport address from which it
   received the DATA or control chunk to which it is replying.  This
   rule should also be followed if the endpoint is bundling DATA chunks
   together with the reply chunk.

Now we discussed the reply chunk in detail and specifically left
the rule as a "SHOULD" since there are times when you
don't want to send back to the place it came from.. your example
is one of these...(we had talked about making it a MUST in
early discussions.. and that just made no sense).

I would think you as an implementor have a number of choices:

1) Bundle the DATA and the SACK and send it to the primary

2) Send just the DATA to the primary and then when the
    Rcv timer pops, send a SACK to the address the data came from.

and I guess you could even go so far as to

3) bundle the DATA with the SACK to the last place the data
    came from.

All of the above our legal and don't violate the spec... however I would
recommend either 1 or 2.

This for a number of reasons:

1) You are already in theory sending DATA to the primary, so it is
     likely to have the best cwnd to allow your data to go out.
2) You probably (aka same reason as 1) have a better RTT estimate
     of the primary
3) Its where you picked as the primary and where the user "expects" (if
   he/she expects at all)  the data to go.

Now I would bundle the sack and data if possible but either choice would
be ok... sometimes they won't all fit together (as we know) depending on 
the size
of the chunks :>

Not that I have answered your questions.. other than the fact that any
choice is legal.. its just some may be better for performance than others :>

R

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (GNU/Linux)
>
>iD8DBQE/grSnXAsLBNOCSsARAmldAJwL23bzloAD8RYNLujdCM4CTwckIwCfQ+n3
>xkKQ6Cf/4QFtxrwZDevc/MQ=
>=tE9T
>-----END PGP SIGNATURE-----
>
>
>  
>

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: Andreas Jungmaier <[email-masked]>
Date: Wed, 8 Oct 2003 11:18:52 +0200

Hi Randy, dear all,

I stumbled across this question when I was testing my new OPNET
simulation model (which is coming along nicely after I sorted out
some initial problems):
I simulated a path failure of the primary path. Both endpoints A
and B are continually sending data. Now, when B sends retransmissions 
over the secondary path, and A in turn sends [SACK+New Data] chunks over the 
primary (where they are dropped), B's retransmissions actually come 
through (as they are sent over the secondary), but B only learns
of this after the third retransmission (second retransmission takes
the primary path again), when A receives duplicate TSNs and immediatly
returns the SACK over the secondary (as per section 6.2 of RFC 2960).

In this case, the behaviour is not optimal, I think, and I was kind
of surprised by this when I had the simulation run :-)
Or am I overlooking something ?

Best regards,
Andreas

- --

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 8 Oct 2003 19:42:48 -0400 (EDT)

I'm not sure about others, but I am having a hard time following your
example and the problem you describe. Can you reword the scenario?

~armando

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

On Wed, 8 Oct 2003, Andreas Jungmaier wrote:

> WARNING: Unsanitized content follows.
> iD8DBQE/g9aCXAsLBNOCSsARAkdJAJ48NHJiCwc1LF84EeaoOjw0bhbWMgCgoR5C
> ZQ4f1EPYMJ6Us9mLCdsP8b0=
> =eRrH

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 9 Oct 2003 11:43:54 +0200

Armando,

I will try:

 0-----0 (A1)----------------PRIMARY----------------(B1) 0-----0
 |  A  |                                                 |  B  |
 0-----0 (A2)----------------SECONDARY--------------(B2) 0-----0

Both endpoints A and B are continuously sending data towards the
peer over the primary path. At some time T the primary path fails
(e.g. due to a hardware failure).
T3 times out (say for B) after the RTO (of the primary path of B).
B retransmits the earliest outstanding chunks over the secondary
path, towards A2.
When the  retransmitted chunks arrive on A2, A will start a 
SACK timer to expire after 200 ms (assuming that that is the
SACK delay).

Now, since A still sends new data chunks continuously over the
primary path (towards B1), it may happen that when the SACK timer
is running, the SACK is bundled with the outgoing new data, and is
sent over the primary path. Where it is dropped, of course.

Then, T3 will expire again for B, this time indicating that the chunks
sent (and: retransmitted) to the secondary path have not been ack'ed.
Then these are retransmitted again, over an alternate path,
and this time over the primary, where they are dropped again.

Then the T3 timer will expire for the primary path, and retransmit
the earliest outstanding bytes over the secondary path. When this
retransmission arrives at A, it is ack'ed at once (since the TSNs
are duplicates) and the path error counter and association error counter
are reset for the secondary path and the association, respectively.

This behaviour initially struck me as weird, and I thought that I was either
overlooking something in my simulation model, or had implemented the specs
in an incorrect way.

The way I handle this now is: if a SACK timer is running and the
next outgoing data goes to a path that is different from the path
where the last data arrived from, then leave the SACK timer running,
and do not bundle the SACK at once, but send it back to the path
where last data arrived from (which is solution 2 mentioned in
Randy's earlier posting).

Hope that clears the clouds :-)

Best regards,
Andreas

> > > All of the above our legal and don't violate the spec... however I
> > > would recommend either 1 or 2.
> > >
> > > Now I would bundle the sack and data if possible but either choice
> > > would be ok... sometimes they won't all fit together (as we know)
> > > depending on the size
> > > of the chunks :>
> > >
> > > choice is legal.. its just some may be better for performance than
> > > others
> > >
> > >
> > > R
> >
> > - --

- --

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Oct 2003 04:42:40 -0600

Andreas,

I don't understand how B's T3 timer can timeout three times
(presumably being doubled each time) before A's T3 timer expires
the first time.  Could you please explain?

--brian

On Thu, 09 Oct 2003, Andreas Jungmaier wrote:

> iD8DBQE/hS3aXAsLBNOCSsARAhszAKCG8A3RmvhrmZZSImUJufnw44CQNwCdHB3d
> H+BbcPaYkdkp+oCjWi2nL2Y=
> =B8Vm

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

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 9 Oct 2003 13:18:01 +0200

> the first time.  Could you please explain?
Oh, absolutely. It does expire in the same way as B's  T3 Timer.

Andreas

- --

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Oct 2003 05:55:13 -0600

Andreas,

The perhaps you can explain the scenario again with A's T3
timer timing out instead of always sending on the primary?

--brian

On Thu, 09 Oct 2003, Andreas Jungmaier wrote:

> iD8DBQE/hUPpXAsLBNOCSsARAm55AJsHYEdpRIqh0/Qh1E+HTgOa8pbzXACggK14
> Zv2gJXyAQGl7qYTQnbI9KWU=
> =pHg5

---

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 10 Oct 2003 13:38:36 +0200

Dear Brian, dear all,

never mind. The description of this scenario would become quite 
lengthy and would - most probably - neither enlighten you nor me
nor anyone else on this list.

I think I found what seems to have been the reason for what 
puzzled me in the first place: the RTO of the secondary path
was still at the initial RTO (i.e. 3 seconds).

That considered (and setting RTOs for both paths equally to 1 second), 
the options 1 and 2 Randy mentioned earlier in this thread cause a similar 
(though not equal) behaviour with respect to recognition of path failure.

Best regards,
Andreas 

- --