Subject: RE: [Tsvwg] SCTP Multihoming issue

From: [email-masked]
Date: Wed, 22 Aug 2001 15:47:56 +0300

> > Is the retransmission of a few packets on changeover from one path to
> > another really a big issue?  How often do you expect to change the
primary
> > address?
> 
> - The retransmission of these packets could happen everytime a changeover
> is done. So, even if the changeover is done only once, it is very
> likely that it won't be smooth.
> 
> - The sender's cwnd is also blocked for at least an RTT (could be more in
> some circumstances) since the retransmitted packets now take up cwnd space
> on the new destination. This prevents the sender from sending new data
> during that RTT(s).
> 
> - You _could_ think abt the SCTP sender as being more aggressive, since
> all the retransmissions are unnecessary.
> 
> My concern is to make the transient behaviour during a changeover as
> smooth as possible.
> 
> regards,
> jana
> 
> >
> > Jon

	Think also that this situation will happen as well if the upper user
explicitly specifies the destination address to be used to send one concrete
SSN. If the SSN must be fragmented into more than 3 TSNs, and the
destination specified is not the Primary Address, I think you will suffer
exactly from the same problem... :-/

	If cwnd of IP1 wasn't 2 but 4 or more at the moment the transmission
takes place, you would retransmit almost all the buffered packets... In the
example, I think you would unnecessarily retransmit 49 TSNs... :-<, they are
not really a few...

	We don't really know if it is a big issue, what when Jana discovered
it we though that it was worthy asking for comments in the list... :-0

	BR Iván Arias Rodríguez

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 22 Aug 2001 12:25:52 -0500

Essentially we are talking about the traffic behavior when _multiple_
destination addresses are involved _simultaneously_ in data transmission
(this can happen either during the changeover of the primary address or
when the upper layer intentionally directs data across different
destination addresses).

Throughout the development of SCTP, we made it very clear that this
"simultaneous, multi-path data transmission behavior" was a research
topic (I remember Chip Sharp suggested that this could be a good
research project for a Ph.D candidate).

There was no intention in SCTP design to address how traffic control
should be done under such condition. This is the primary reason we
removed round-robin from SCTP and made it a guiding principal that "SCTP
multi-homing was NOT meant for traffic sharing, but only for path
redundancy!"

I don't think we know enough about "simultaneous, multi-path data
transmission behavior" over Internet, nor do I think the time is mature
for us to talk about "solution" to modify SCTP for this purpose.

Therefore, my suggestion would be to stick with the principal that "SCTP
multi-homing is only for path redundancy." If your primary address fails
and you have to failover to an alternate, you shouldn't be surprised to
see some disturbance in the traffic pattern.

-Qiaobing

---

From: Kacheong Poon <"kcpoon"@eng.sun.com>
Date: Thu, 23 Aug 2001 02:47:05 -0700

> see some disturbance in the traffic pattern.

I think I need to clarify the proposed solution.  Actually, the 
solution is not for the observation Ivan and Jana saw.  It is for
patching the weakness that congestion control in one association can
be easily gotten around by switching primary addresses.  I agree that
doing load sharing using multiple addresses is a research issue.  But
I think that allowing an app to circumvent congestion control by
switching primary addresses is a weakness.  Yes, an app can do the
same thing by opening multiple associations, just like opening 
multiple TCP connections.  But to have the weakness within a single
association is a different issue.

If the rationale behind having multiple addresses is for redundancy,
then it is reasonable to limit the number of data in the network
when the switch happens.  Consider the case that the swtich of
addresses happens because of real network outage.  Then it is 
reasonable to slow start using a new primary address.  This is
definitely a very conservative behavior.  If the path to the new 
primary address is completely different from the path to the old
one, I agree that we do not need to be that conservative.  But since
SCTP cannot, in general, have this kind of info, it seems to me that
it is better for us to be conservative at this point of SCTP
deployment.

							K. Poon.
							[email-masked]