Subject: RE: [NSIS] layer split summary? opinions?

From: [email-masked]
Date: Wed, 5 Feb 2003 09:57:32 +0200

Hello all,

> This is only a problem if there is a long delay in the pipe. Otherwise, 
> UDP or TCP, the message will be delivered after the same time. (If you 
> believe head-of-line blocking matters, SCTP would presumably address 
> that problem.)

A somewhat crazy idea popped into my head, based upon Henning's text.
As most of you know, SCTP supports multihoming, allowing support for
multiple data paths between SCTP endpoints.  Could SCTP, when used
as an NSIS transport (below NTLP) provide more path robustness?  
The question is, however, can we engineer something using SCTP that
intermediate nodes 'sniff' the NTLP/SCTP packets to see if they are
concerned about the contents?

br,
John
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 05 Feb 2003 12:10:53 +0100

John, all,

Interesting suggestion. SCTP association has assumed be one candidate 
for transporting NSLP (e.g., CASP client as in CASP proposal) data for 
each pair of neigboring NTLP nodes. Following recent investigations on 
SCTP for mobility, add-ip (as well as delete-ip) operation with SCTP may 
make it also possible to deal with route change (of which mobility is a 
special case) while maintaining a same association for the neighboring 
NTLPs using SCTP. This association can also be used for dealing with 
route change, where a SCTP/NTLP API should be able to trigger such a 
local repair and therefore an NTLP/NSLP API triggers further repairs for 
NSLPs states. I think this assumption/requirement is valid with a 
two-layer architecture. On the other hand, using SCTP may implicates 
that session/flow identifiers may be hiden (of course we can break the 
normal hierarchy and look into lower layers as well), which are 
potentially useful in some signaling applications.

Best regards,
Xiaoming