Subject: RE: [Tsvwg] SCTP Multihoming issue (looking for a solution).

From: [email-masked]
Date: Wed, 22 Aug 2001 03:35:43 +0300

Hi again!

	Well, as modified by the Implementors Guide, when a SACK comes with
a Gap ACK Block, only the missing counters of those unacknowledged TSNs
older than the newest newly acknowledged TSN (let's call it the NNA TSN) in
the incoming SACK are incremented... This provides some protection against
packet reordering (actually the example in the other mail is a (special?)
case of reordering in which the reordering is introduced by the sender
itself), but not for the case shown in the example. Let's call to this way
of doing the "A behavior".

	The preliminary idea follows the rule above, but also, links the
increase of the counter to the last address used for sending the TSN. So, we
should keep on memory the NNA TSN in the SACK for every destination
address... But, as when there are gaps a SACK is sent every single packet,
the point is that you keep the same information as before (the NNA TSN) plus
the information of which was the last address used to send that NNA TSN. So
you only increase the counters of those TSNs older than the NNA TSN which
were ALSO sent to the same destination address as the NNA TSN. This is the
"B behavior".

	"B behavior" in a way separates the fast retransmission of TSNs sent
to an address or another. This is because it is quite possible that TSNs
sent to different addresses are disordered (in "wide multihoming", when your
source or destination IP addresses are located in different networks, I
think that this is even likely...), but they should normally arrive in order
relative to the TSNs sent to the same address... In my opinion, multihomming
could greatly increase the possibility of reordering at the destination
(hopefully one will use most of the time the primary address), but this
should be verified first... :-/

	So that's the reason of the "B behavior"... The problem with it is
that if in the previous example the TSNs sent to IP0 were really lost, one
could need a time out to retransmit some of those lost TSNs. This would
happen in case any of the last 4 TSNs is lost (in that case the fast
retransmit counter of a lost TSN could at most reach 3 strikes if no more
that 3 TSNs sent later than it reached the destination). With B behavior
this is extended not only to the last TSNs sent, but also to the last TSNs
sent to every destination.

	So, to palliate this, there is still a C behavior. Here you increase
the same TSNs as in B behavior, but also, those TSNs that are older than the
NNA TSN, even if they were sent to a different address than the NNA TSN, BUT
whose missing counter is bigger than 0. This makes that if a TSN sent to IP0
in the example is lost, but any TSN sent later than it reaches to the
destination, with the help of the SACK originated by the TSNs sent to IP1,
those lost TSNs will be eventually fast retransmitted. Of course, in the
example, if the last TSN sent to IP0 (TSN 50) is lost, it won't even be
retransmitted (TSN 50, and all the previous lost TSNs lost in a row: 50, 49,
48... up to the last TSN that really arrived to SCTP B).

	So, C behavior, somehow helps to avoid a fast retransmission (if the
conditions of the example are followed) when the upper user changes the
Primary Address or simply decides to send some specific SSNs to a concrete
destination different than the Primary Address, but at the same case it can
disallow the fast retransmission of some TSNs in the case that the last TSN
sent before the change of the Primary Address is lost... However, one should
note that as the time out would happen in an address different than the
current Primary Address, the consequences are not that hard.

	So that's all folks! I hope that if this fast retransmit is really
considered an issue, somebody could provide a solution, or at least some
comments about the stated in this mail...

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 22 Aug 2001 10:18:20 -0500

Ivan:

Interesting ideas for sure. In your B behavior you are really
(in simple terms) just apportioning the NNA TSN to the respective
networks (if you will). This in effect prevents your switching 
behavior.

Your C solution takes this a bit futher so that if you get
1 report then you also start to count NNA TSN for other networks. In
effect you violate your B behavior if there is a single strike
against a chunk and go back to the A behavior...

Now I am wondering if this might have an adverse effect on things
when you also get packet re-ordering. Say the last 3 packets are
re-ordered. Then by the time some of the GAP-ACK's start to
stream in you may well end up doing a FR on the last 3 packets...

Also I wonder somewhat as Jon did, is this really that big of
deal. The idea of the alternate destinations is to provide a
redundant backup for retransmissions. Not necessarily for
an app to be switching back and forth. 

Secondly I wonder how much you would really have unmatched
links when accompanied by switching. I think you may find
a bit better behavior when the two links are evenly matched.
You will get some false fast retrans I am sure but not
as many. Since I would think the propagation delay would 
come in to mitigate this somewhat. 

And even beyond that, you are dealing with a very very
specific corner case in my mind...

a) I am sending loads of data
and
b) I switch primary's at the same time.
and
c) All of my data is inqueue to the nic which means
   I am the only one using it and I must have set up
   my socket buffer capacity very large so I can get
   so much in queue.
and
d) the cwnd is quite large

1) Why would I switch destinations when I am getting good
   performance out of a network?

2) Why would I be using the 10M lan instead of the 100M if
   I had any idea one was better than the other... which doing
   app switches of the primary implies.

I don't think you can plug all the corner cases in any event without
possibly harming something else..

Your B solution seems logical and it does not even have to
be specified to do it... since it is an internal implementation
choice (more or less).... We could specify it I guess as an
option.. 

Your C solution seems to me fraught with peril and I am not
too confident in it.. I would have to play with a simulator
and think on it a bit more before I would be willing to sign
on to it :)

R

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

---

From: Janardhan Iyengar <[email-masked]>
Date: Wed, 22 Aug 2001 12:17:12 -0400 (EDT)

Randall,

> a bit better behavior when the two links are evenly matched.
It is a _bit_ better with matched links. But really, the problem is not
that the links are unmatched, it shows up when the data queues up on one
nic, and new data starts going out on the other link, and I am in no
position to comment about how common/uncommon this is (or will be).
A large cwnd only amplifies the problem.

regards,
jana

-----------------------------------------------------------------------
Janardhan R. Iyengar				   [email-masked]
University of Delaware		       http://www.cis.udel.edu/~iyengar
-----------------------------------------------------------------------

---

From: Randall Stewart <[email-masked]>
Date: Wed, 22 Aug 2001 11:47:27 -0500

I think I like Kacheongs email suggestion better with
a slight modification by me... I am not sure he sent it 
to the list..

1) When switching primary destination addresses, the flightsize
   of the old primary is considered part of the new primary
   flight size as well, until of course the CUM-ACK passes
   the point where the switch happened.

2) A switch on demand per packet will be treated as in 1) above
   as well. This way if you override, that network that you
   override to picks up the flightsize of the primary.

These two would leave the current useage of the alternate (i.e.
redundancy) untouched and yet at the same time leave a proper
dis-insentive to switch destinations for no reason.. better
to let SCTP do it.