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

From: [email-masked]
Date: Wed, 22 Aug 2001 20:49:09 +0300

Hi, some comments...

> -----Original Message-----
> From: ext Randall Stewart [mailto:[email-masked]]
> Sent: 22. August 2001 19:47
> To: Janardhan Iyengar
> Cc: Arias-Rodriguez Ivan (NRC/Helsinki); [email-masked]
> Subject: Re: [Tsvwg] SCTP Multihoming issue (looking for a solution).
> 
> 
> I think I like Kacheongs email suggestion better with
> a slight modification by me... I am not sure he sent it 
> to the list..

	I think he didn't...

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

	I don't really see how this would work... Do you mean considering
all the outstanding data in the old primary as being also outstanding in the
new primary? Outstanding on both or just on the new primary?

	I think that such a modification would cause problems when receiving
the SACKs... When an outstanding data is acknowledged, the flightsize of the
address to which it was sent the last time is decreased by the length of the
data acknowledged... Unless you make a trick changing the address you
consider as the "last one used" of those outstanding DATA chunks, I imagine
that you will end up having either a negative flightsize on the old primary
address or "ghost flightsize" which is somehow bigger than 0 even if there
aren't any outstanding TSNs...

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

	Same comments as before...

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

	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 12:53:59 -0500

Ivan:

I don't see this as a hard problem to implement.. all you
do is have an additional flight-size variable...

Flight-size-from-setprimary

When someone does a setprimary this gets set to the flightsize
of the old primary.

Yes, you have to maintain two flightsize's i.e. has the SACK
lowers things on the old primary you would have to lower
things on your additional variable. You would probably also
keep a TSN-At-setprimary as well so that you could use this as
a marker to besure  to zero F-S-F-S when it passed it.

I don't see it as any harder to implement than your propsal and
I do think it is quite safe..

R

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