Re: [Tsvwg] F-RTO and SCTP (was: SCTP Timestamps)

Qiaobing,

I agree.  And please do not forget that SCTP was first designed to
meet a set of requirements for transporting telephony signalling
protocols.  If those requirements fail to be met by SCTP, yet another
transport protocol will become necessary again.

--brian

On Tue, 05 Aug 2003, Qiaobing Xie wrote:

> Kacheong Poon wrote:
> 
> > ...I'd suggest
> > those SCTP stacks to support ASCONF so that the retransmission
> > can automatically be made to an alternate address.  This seems
> > to be a better way to handle it than relying on a "guess" of NIC
> > failure as there is no need to guess at all.
> 
> So you want to rely on an external monitor/detector mechanism at the
> peer endpoint that will tell the peer SCTP stack a NIC is bad and then
> the remote stack will do a "change primary addr" through ASCONF so that
> the local endpoint will start to move the traffic to an alternative dest
> addr? Ok, now you have no need to guess since the remote external
> detector is doing the "guessing" :-)
> 
> But this would essentially remove most of the SCTP's auto path failure
> detection / recovery capabilities and take out a big chunk of SCTP's
> multi-homing advantage. I think this is too costly for whatever we are
> trying to gain here.
> 
> regards,
> -Qiaobing
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ 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
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg