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

From: [email-masked]
Date: Wed, 22 Aug 2001 19:28:04 +0300

Hei!

	See my comments below...

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

	Yes, that's it. The point is that if you already received a missing
report on some chunks, it means that either reordering inside a simple
network or packet lost is happening... So in that case you basically change
the behavior to the A mode for those TSNs...

	As you can see, a Fast Retransmission of a TSN is more likely to
happen in A mode, then in C mode, and finally in B mode...

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

	I imagine you refer to C mode. Yes, that's true, but that is what
will anyway happen using the A mode (which is the one recommended
nowadays...)

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

	Yes, that's we Jana and me were wondering if the change would be
worthy... :-/ But in any case, as the possibility of doing it is there, I
think that some application might make use of it... As Kacheong pointed in
another replay to this mail (and what I think was one of the initial ideas
of how multihoming capabilities could be used), one could make load sharing
among several address, thus actually improving your sending skills sending
more data than normally using the Primary Address without violating any spec
rule...

	I don't really know...

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

	I guess that in SS7 that could be usual... but then the other
hyphotesis don't really apply... :-|

	But... at the end the base problem is that you are causing
reordering at the origin due to the use of different nics... I think that it
really doesn't matter if both nics are exactly equal and are connected to
the same LAN (both at the origin and destination), so the TSNs follow
exactly the same path...

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

	Yes, the bigger the propagation delay, the smaller the effect is...
But I think that the values Jana and myself used should be somehow "quite
standard" (we might be wrong)...

> 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

	It would be enough sending a file of, let's say 100 KB...

> b) I switch primary's at the same time.
> and

	Well, yes, you switch the primary not when being especially quiet...
Also as I said in another mail, it applies not only in primary changes, but
also when the upper user states that an SSN must be sent to a different
address...

> 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

	Well... I think that if you are not the only one using the card then
it is even worse, as some other users different than SCTP could be filling
the nic buffer... so producing more delay... Of course, this would apply to
both the primary address and the other one... I think that this would mostly
delay the sending of both the old and new TSNs, but their relative order
would be quite similar... But I don't really know how nics work, so...

> d) the cwnd is quite large

	Not really... You start with a cwnd of 2 MTUs... I guess that
reaching for example 100 is not that hard (actually I did so, but I was
testing bulk data transfer inside my own network...)... Ok, this means that
this would only happen in the middle of a quite long transmission, when the
cwnd had time to grow enough...

	Ant the cwnd of the secondary address was set to the normal value
for an idle address, 2, in the example...

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

	I could think about a HTTP server sending a web page containing
several jpgs, gifs and stuff, which not only uses streaming for transmitting
different files, but also load sharing among the addresses used by the
client, just to make the whole data transfer quicker... I think this could
be quite common if SCTP somehow replaces TCP in the Internet... People tend
to do "strange" things... :-)

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

	Yes, Jana a me spoke about that... But you should note that the
difference 10-100 Mbps only makes problem worse, but the retransmissions are
also triggered when both LANs are equal (10 vs. 7 TSNs retransmitted in the
example)...

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

	Yes... The point is that we don't really know the answer to the
question "how common is this situation?"... even worse, we should try to
answer the question "how common WILL BE this situation?"... I know you know
more about this that us... maybe some other folks can also say if they
really think that the situation could be common enough so to worry us...

> 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 :)

	I think that the C mode is somehow more conservative than B, in a
way that it leaves things happen in a more similar way to the A mode... I
think B avoids the FR caused by this situation, but what about if the
packets were really lost?, a time out on IP0 doesn't affect that much to
IP1, but waiting for the time out to retransmit the lost packets could make
that the receiver is not able to send data to the upper user during that
time, and the rwnd could even avoid new transmission of data... FR means a
retransmission, but also means that it is fast... :-)

	C mode avoids those FR as well, unless some reordering (lost?) is
happening among the TSNs sent to a specific address... In that case we
basically change to A mode...

	I'm less convinced today that this is really an issue when Jana did
the ns simulations, but let's see what people think about...

	BR Iván Arias Rodríguez

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