Subject: [Fwd: Re: [Tsvwg] again load sharing]

From: giuseppe <[email-masked]>
Date: 09 Apr 2003 14:08:57 +0200

Subject: Re: [Tsvwg] again load sharing
From: giuseppe <[email-masked]>
To: [email-masked]
Date: 09 Apr 2003 14:07:54 +0200

I do not agree totally. Maybe I do not understood the matter.But...
Il mer, 2003-04-09 alle 13:07, Brian F. G. Bidulock ha scritto: 
> giuseppe,
> 
> That does not make SCTP "unfair" to TCP.  Each destination will still
> back off exponentially and grow linearly.  TCP connections can only
> be to one destination.  SCTP multihomed associations in competition with
> TCP connections to the one of its destination will behave the same as
> a TCP connection to that destination.  As long as SCTP acts as a single
> TCP connection to each destination, it will behave no differently than
> a TCP connection made to each destination. 

Sure. But let suppose that in the point (router) R1 arrive one TCP
connection and one SCTP connection (with load sharing turn on). In
steady state SCTP single connection (we mean for connection the couple
(source address, destination address) behaves fairly with TCP
connection. And they equally share the capacity. Same for the other
connection (i.e. the other possible couples).
But if we suppose that all the couples, i.e. all the connections of the
SCTP, traverse the same POC (in this case R1), SCTP grabs more capacity
than TCP, and more, the dropping probability augments . If the common
point traversed were a POC, this "probabily" would not happen and the
load sharing would be "effective".
In my discussion I suppose we are able to fairly select the real path
(i.e. the couples...), maybe by using the source addressing mechanism. 

>  In face SCTP is disadvantaged
> by source address/destination address path mappings.  That is, when
> SCTP has two sources (A and B) and two destinations (C and D) it behaves
> as thought it were two TCP connections, one to each destination.  But
> 4 TCP connections can be formed: A-C, B-C, A-D, B-D.  This means that
> TCP can compete unfairly with SCTP in unbalanced networks or in networks
> where source address based routing is performed (e.g. disjoint networks).
> Where source address based routing is not performed (normal case, common
> points of congestion), the situation is quite fair.
> 
> --brian

We detected that there is an other problem in load sharing with SCTP:
the problem of unique CTSN variable. In fact, the SACK could increment
also the congestion windows associated with paths where there has been a
dropping event...
So, I am waiting your helpufl comment.

> On Wed, 09 Apr 2003, giuseppe wrote:
> 
> > Il mer, 2003-04-09 alle 11:49, Brian F. G. Bidulock ha scritto:
> > > giuseppe,
> > > 
> > > On Wed, 09 Apr 2003, giuseppe wrote:
> > > 
> > > > HI. I am investigating the opportunity of load sharing in SCTP. One of
> > > > the thing I not undertand is when the load sharing is effective. There
> > > > are situations in which load sharing is effective? 
> > > 
> > > Load sharing is effective in any situation where both the available
> > > bandwidth of the network and the offered load exceeds the available
> > > bandwidth of any one interface.  (Or a similar situation with regard
> > > to latency if latency is of concern.)
> > > 
> > > OTOH the algorithm for load sharing can have interactions with SCTP
> > > protocol mechanisms (retransmission, gaps, SACKs, bundling) and could
> > > reduce efficiency in some circumstances depdending on network
> > > conditions.
> > > 
> > > IMO algorithms that more closely correspond to SCTP's "primary"
> > > destination approach will have more success than those that deviate
> > > widely from it.  All other factors equal, a sender should not load-share
> > > to a secondary destination until the primary destiation's congestion
> > > window has been sent.  This or similar procedures should have the effect
> > > of grouping as many sequential TSNs as possible to the same destination,
> > > avoiding excess gap detection and reporting due to difference or
> > > variance in OWT between destinations over which traffic is being
> > > loadshared.
> > > 
> > > > Second, is there anyone who is attempting to response to this question:
> > > > when two links are un-shared? In my opinion two link are unshared when
> > > > they do not cross same Point Of Congestion. So, detecting at run-time
> > > > this event is a very hard challenge....
> > > 
> > > SCTP's congestion procedures do not make assuptions about the underlying
> > > network and are resilient to network changes independent of network
> > > topology.
> > 
> > 
> > > Where is the challenge?
> > > 
> > HI BRian, thanks for the quick response.
> > I mean this. If one want sent data source over all the available paths
> > (i.e. by using load sharing), it could happen that some paths (let
> > suppose 2 for example) share a Point Of Congestion. Thus, sending at a
> > send rate greater than of a single TCP connection sharing the same POC,
> > could lead to an unfairness problem. In practice, we do not reach the
> > well known sqrt(p) relation of the TCP throughput...
> > 
> > > --brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Apr 2003 06:39:30 -0600

giuseppe,

> (i.e. the couples...), maybe by using the source addressing mechanism. 

Under congestion during load-sharing, the cwnd of each of N destinations
will fall to 1/Nth of TCP's cwnd to the one destination and, everything
is quite fair.  The only place that SCTP might take advantage in load-
sharing is during slow-start, however, an effective load-sharing algorithm
could avoid loadsharing over multiple destinations in slow-start.

> also the congestion windows associated with paths where there has been a

I don't see the problem here: could you describe this further?

--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: giuseppe <[email-masked]>
Date: 09 Apr 2003 15:24:56 +0200

Brian, let consider this raw figure:

		----- 			------
		|TCP|			|TCP|
		-----			------
		  |			   |
--------	  O------------------------O		-------
|SCTP A|__________|			   |____________|SCTP 1|
|      |                                                |      |
|SCTP B|----------O------------------------O------------|SCTP 2|
--------						--------

Suppose we are in load sharing, i.e. we send out data over A-1 and B-2
jointly.
The RFC say that the congestion window must be incremented when :
1) the variable CSTN at sender is lower than the CTSN-AP
2) new data are acknowledged on the associated path
Let suppose u send 1-2-3-4 on the path A-1 and 5-6-7-8 on the path B-2.
A loss of the packet 5 occurs. A SACK on 1-A, with CSTN-AP=4 and a
GAPstart=6 and a GAPstop=8, will increment the CWND both on the A-1 and
B-2 path. This is the problem to have a unique CSTN.
More, in the figure load sharing is fair. TCP compete fairly with A-1
SCTP.
But what happen if also B-2 traverse R1-R2 path? SCTP grabs more
bandwidth with respect to TCP? To me, yes. Moreover, if R1-R2 is
congested (high p), adding an other connection will further increase p.
 giuseppe

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Apr 2003 07:59:34 -0600

giuseppe,

> Brian, let consider this raw figure:

Only the congestion window for the destination to which data was sent
is incremented and then only if the data is cumulatively acked and
the data was not retransmitted.  I still don't see a problem.

> bandwidth with respect to TCP? To me, yes.

No. SCTP's cwnd for each desitination would fall to 1/2 of TCP's cwnd.

> Moreover, if R1-R2 is

---

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 11 Apr 2003 10:19:46 +0200

Hi, all,

please see my comments inline:

On Wednesday 09 April 2003 15:24, giuseppe wrote:
>
> 		----- 			------
> 		|TCP|			|TCP|
> 		-----			------
>--------        O------------------------O            --------
>|SCTP A|________|                        |____________|SCTP 1|
>|
>|SCTP B|----------O----------------------O------------|SCTP 2|
>--------                                              --------

> congested (high p), adding an other connection will further increase p.

In that configuration, SCTP behaves essentially similar to two 
TCP connections. So, one SCTP association probably grabs more 
bandwidth than one TCP connection. 

However, it still behaves in a fair manner toward the TCP connection.
Also, the SCTP association is bound by the receiver window (RWND), meaning
that there is a limit that is enforced on the SCTP association as a 
whole. 

Now, if you have 2 TCP connections, these are both limited by
their respective receiver windows. So these 2 may, *depending on the
parameters of the network setup*, take more bandwidth than one SCTP
association with dual-homing and load-sharing.

My 2 cents,

Andreas

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

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

---

From: Janardhan Iyengar <[email-masked]>
Date: Fri, 11 Apr 2003 13:15:41 -0400 (EDT)

Hi Andreas/all,

> However, it still behaves in a fair manner toward the TCP connection.

I don't think I agree. If a single SCTP association behaves as
aggressively as two concurrent TCP connections, I do not think it is being
fair to TCP.  For one, when comparing a single TCP connection with an SCTP
association performing what we call "Concurrent Multipath Transfer (CMT)"
(or load sharing) with a shared bottleneck, a single loss event at the
bottleneck does not result in the same reduced cwnd for the TCP connection
and the SCTP-CMT association.

> association with dual-homing and load-sharing.

Agreed. But I think we should be comparing 1 TCP connection with 1 SCTP
association. Or am I missing something here?

Guiseppe: I am currently involved in End-to-End Concurrent Multipath
Transfer at the Transport Layer. With regard to your comment about "unique
CTSN variable", there are a few things that come to mind. But I'm not sure
what you are referring to. If you do have some specific questions
with regard to what you are observing, maybe you could get back to me
offline?

regards,
jana

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQE+lnqiXAsLBNOCSsARAkHvAKCX1+jVWVTrIqvhGjMkFo9vEMXtfQCcCuP7
> lJxY8CujFU6B2LJbNDiY3T8=
> =m+Tj
> -----END PGP SIGNATURE-----
>

-----------------------------------------------------------------------
Janardhan R. Iyengar		       http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab			 University of Delaware
-----------------------------------------------------------------------