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

From: [email-masked]
Date: Wed, 22 Aug 2001 21:06:16 +0300

Uhm... I see what you mean, but I don't really understand yet how
this could work either...

	It is likely that the cwnd of the new primary will be set to
2*MTU... so, I guess that using that formula, you will end up waiting for
the SACKs to arrive, until the flight size shrinks to less than 2*MTU... not
sending new data meanwhile...

	Is it what you mean Randall?

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Randall Stewart [mailto:[email-masked]]
> Sent: 22. August 2001 20:54
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] SCTP Multihoming issue (looking for a solution).
> 
> 
> 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
> 
> [email-masked] wrote:
> > 
> >         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
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

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

Yep,

Basically you would then take a hit/penalty when
you switched networks that would mean all of your previous
data would need to drain from the network has you
start using the new one.

R