Subject: [NSIS] new draft "GIST over SCTP" and some comments to GIST

From: Xiaoming Fu <[email-masked]>
Date: Sun, 16 Oct 2005 18:50:52 +0200

Hi all,

We have submitted a new Internet draft on running GIST over SCTP, with 
the following abstract:

Abstract:
    The General Internet Signaling Transport (GIST) protocol currently 
uses TCP or TLS over TCP for connection mode operation.  This document 
describes the usage of GIST over the Stream Control Transmission 
Protocol (SCTP). The use of SCTP can take the advantage of features 
provided by SCTP, namely streaming-based transport, support of multiple 
streams to avoid head of line blocking, and the support of multi-homing 
to provide network level fault tolerance. Additionally, the support for 
some extensions of SCTP is also discussed, namely its Partial 
Reliability Extension and the usage of TLS over SCTP.

Before it appears in IETF I-D repository, you can find it in the 
following URL: 
http://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sctp/draft-fu-nsis-ntlp-sctp-00.txt

We would appreciate it if you would review and comment on the draft.

We have also performed a prototype implementation for the basic SCTP 
support in GIST which we plan to include in the next release. In 
addition, we would like to point to some observations/questions about 
GIST thru this work:
- Multi-homing: our analysis show that any multi-homing scenario (e.g., 
host multihoming or AS level multihoming) may involve non-marginal 
consideration in GIST level state management and likely additional 
objects or readapted Stack-Proposal/Stack-Config-Data may be necessary. 
See some preliminary discussions in Section 3.4.
- API: should Transfer Attribute be constrained to only two values 
(Reliability, Unreliability)? What if the NSLP requires partial 
reliability? See more discussions in Section 3.4.1 in this I-D.
- In general, what if the two GIST peers do support a same type of 
transport mechanism, but not the same protocol version (e.g., TLS1.0 
v.s. 1.1, TCP with Reno v.s. with NewReno, as well as above-mentioned 
standard SCTP v.s. PR-SCTP, and so on).

Thanks,
Xiaoming

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

---

From: Christian Dickmann <[email-masked]>
Date: Sun, 16 Oct 2005 21:25:02 +0200

Hi Robert,

> in 3.1: IIRC the order of layered proposals is top->bottom, 
> i.e. the other way round. (there is discussion of that at 
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.) 

I will check that again, but IIRC we implemented it in this way and
had not problem in the interop ;)

> 3.4.1: one of the fundamental goals of the API is precisely 
> that it should *not* change to allow the use of SCTP. (this 
> was extensively discussed at the 2004 interim and was stated 
> as a goal in the spec.) so it's unclear what API changes should 
> be needed. But in fact, I can't tell what changes 3.4.1 actually 
> proposes - it describes how to map SCTP features on to the 
> API (which is reasonable), but the API itself seems unchanged. 

You are right. The changes are just how parameters are interpreted. 
So maybe we should rename this section in the next version.
Do I understand you correctly, that this kind of "change" is acceptable?

Christian Dickmann

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 17 Oct 2005 09:55:50 +0100

Hi Christian,

On the API issue, the background to the issue raised at the
interim was that people were concerned that variant GIST
capabilities might develop, with some NSLPs requiring
specific subsets. This would then become a massive deployment
headache. (AFAIK SIP has suffered a little from this problem.)
So, the design goal of the API has been to be universal, 
regardless of how GIST is implemented. In fact, you'll find
that appendix B doesn't make any reference to how GIST is
implemented (use of TCP, TLS, or even C/D mode). That is
quite deliberate.

So the summary is: you can make any changes you like in the
spec to explain how the API is supported, e.g. to make
best use of SCTP. However, you shouldn't (we hope) have to
change the content of Appendix B.

r.

> -----Original Message-----
> From: Christian Dickmann [mailto:[email-masked]] 
> Sent: 16 October 2005 20:25
> To: "\"Hancock"@www.difra-computer.de; Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] new draft "GIST over SCTP" and some 
> comments to GIST
> 
> 
> Hi Robert,
>

---

From: [email-masked]
Date: Mon, 17 Oct 2005 12:57:04 +0300

I agree with Robert about the background and the goals of what
we are trying to do with the API.

John 

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Hancock, Robert
>Sent: 17 October, 2005 11:56
>To: Christian Dickmann
>Cc: [email-masked]
>Subject: RE: [NSIS] new draft "GIST over SCTP" and some 
>comments to GIST
>
>Hi Christian,
>
>capabilities might develop, with some NSLPs requiring specific 
>subsets. This would then become a massive deployment headache. 
>(AFAIK SIP has suffered a little from this problem.) So, the 
>design goal of the API has been to be universal, regardless of 
>how GIST is implemented. In fact, you'll find that appendix B 
>doesn't make any reference to how GIST is implemented (use of 
>TCP, TLS, or even C/D mode). That is quite deliberate.
>
>spec to explain how the API is supported, e.g. to make best 
>use of SCTP. However, you shouldn't (we hope) have to change 
>the content of Appendix B.
>
>r.
>
>> Subject: Re: [NSIS] new draft "GIST over SCTP" and some comments to 
>> GIST
>> 
>> 
>> Hi Robert,
>> 
>> > in 3.1: IIRC the order of layered proposals is 
>top->bottom, i.e. the 
>> > other way round. (there is discussion of that at
>> > 
>> > 3.4.1: one of the fundamental goals of the API is 
>precisely that it 
>> > should *not* change to allow the use of SCTP. (this was 
>extensively 
>> > discussed at the 2004 interim and was stated as a goal in 
>the spec.) 
>> > so it's unclear what API changes should be needed. But in fact, I 
>> > can't tell what changes 3.4.1 actually proposes - it describes how 
>> > to map SCTP features on to the API (which is reasonable), but the 
>> > API itself seems unchanged.
>>

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 19 Oct 2005 16:27:59 +0100

hi,

another level of '>' ;-)

[snip]
> i think this is viable way.
> > 
> >  > - two neighboring GIST peers are multihoming. This may be
> >  > related to how
> >  > to represent multiple IP address pairs in the MA entry 
> (or just the
> >  > "node identifier" of its peer), in connection with SCTP
> >  > association/chunk relationship.
> > 
> > true, but (if you want to) this is already the case even with TCP
> > as a transport for the messaging associations. the way that routing
> > state is bound to messaging associations causes a new association
> > to be set up for each address pair (this is a consequence of the
> > state matching rules), BUT if nodes can determine that they are
> > peering over multiple associations they can use a single one and
> > discard the rest.
> 
> in the case of sctp, it is clear a given gist pair can have up to one 
> sctp association, per rfc2960.

why? 2960 says you can only have one sctp association between a pair
of transport endpoints. but a GIST node can have lots of transport
endpoints (for example, a different sctp port gives you a different
transport endpoint, and i assume that outbound connections come from
different source ports. maybe i'm muddled here...)

> > 
> > it may be that more text could be written (probably implementation
> > guidance) about how this can be done. but i would not tie together
> > the facts that multiple address pairs for routing state are relevant
> > between multi-interface nodes and that SCTP can support multiple
> > address pairs. indeed, even in the non-multi-homed case, the IP
> > peer addresses used in the routing state do not need to be closely
> > tied to the IP addresses used by the transport layer protocol for
> > the messaging association (they are tied together by cookie
> > matching, not address matching). so i certainly would not try to
> > bind the two together in the multi-homed case.
> maybe i am a bit puzzled here - yes a cookie requires to be 
> repeated in 
> the query-response, but the problem here is a mrs is required to 
> identify the right identities of its upstream and downstream 
> peer. which 
> identify should be relied on? in the current world likely 
> will still be 
> ip address i guess.

i guess which identity is used in an implementation depends on 
whether the implementor reads the spec or not. the spec says do 
matching on the cookie (at least, it's supposed to). are you saying
that the spec should be changed to do matching on the ip address
instead?

cheers,

robert h.

---

From: Christian Dickmann <[email-masked]>
Date: Wed, 19 Oct 2005 22:44:41 +0200

Hi Robert,

> that the spec should be changed to do matching on the ip address 

I think I do not understand your discussion. So what I am saying in 
this mail might be out of context, but this is at least a question 
to me:

In a multi-homing scenario, which means, that one GIST node has 
multiple addresses, the node has to choose which IP address should be
used in the NLI. 
Chapter 4.4.2 of GIST draft 08 states: 
"Association re-use is controlled by the Network-Layer-Information
   (NLI) object ...
The NLI object includes:
Peer-Identity: ...
Interface-Address: ... "

This section talks about when MAs can be re-used and it says that 
a match of Peer-Identity is not enough. 
"These should be rare events, so the expense of a new association 
setup is acceptable."

So in a multihoming scenario there might be one association for every
link of the multihomed node.

Maybe you explain this scenario when you say:
"If the authenticated peer identities match after association setup, 
the two Interface-Addresses MAY be bound to the association."
But I do not get what you mean. 

Of course, this is not a SCTP related issue, but in the case of TCP it 
might be a bad thing to re-use the connection, as the choice of the NLI 
address might be intentional to do load-sharing at the multihomed node 
and this load-sharing would not be possible in TCP. Instead in a real 
multihoming supporting transport protocol re-use might be a good thing
here.

I hope I am not too confused right now.

Christian Dickmann

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 19 Oct 2005 23:17:57 +0100

hi christian,

my basic point was that if people implement GIST by doing
identity matching of MAs to flow states by IP address comparison,
rather than by cookie comparison, they are not following what
the spec says (even if IP address comparison is a common 
technique today). But your follow up questions are (as
I might expect) very reasonable. More inline:

> Behalf Of Christian Dickmann
> Sent: 19 October 2005 21:45
> To: [email-masked]

Right. Indeed, if you have a node with N interfaces peering with a 
node with M interfaces, and there are flows traversing every possible 
interface pair (which is an extremely pathological case, but anyway...)
there could be be N*M MAs between them. 

However, the more expected case (I think) would be that even a 
multihomed node would have a relatively small number of peers out of
any single interface, especially if those peers are 'nearby'.

> But I do not get what you mean. 

The intention of saying this is: the usual rule is that messages for
an MRI can only be sent over an MA which was set up using a Q/R/C 
handshake for that same MRI. However, if you know two MAs originate
from the same peer (because of MA authentication), then you can use
them interchangeably. (This may be a case of premature optimisation.
I'd be interested to hear views on that. It might also be reasonable
to be more restrictive, and say that you have to retain all the MAs,
even though you know some of them are redundant.)

> and this load-sharing would not be possible in TCP.

That is also a possible view. Note that it doesn't apply to the
NLI selection by the Querying node (this is found directly and
deterministically from the flow routing), but a Responding node
could do some sort of load sharing by NLI selection. But OTOH,
you could also make a case for saying that it is good for the
NLI selection by the responding node to be tied to the flow 
routing, from a fate sharing argument. I think this sort of 
discussion could be good material for an implementors guide;
I'm not sure how much it has to be pinned down in the GIST
spec itself.
 
> Instead in a real 

I don't think you are :-)
[or at least, it's not your fault.]

robert h.

---

From: [email-masked]
Date: Fri, 21 Oct 2005 09:59:25 +0300

Hi all,

> link of the multihomed node. 

	Right. Indeed, if you have a node with N interfaces peering with
a 
	node with M interfaces, and there are flows traversing every
possible 
	interface pair (which is an extremely pathological case, but
anyway...) 
	there could be be N*M MAs between them. 

	However, the more expected case (I think) would be that even a 
	multihomed node would have a relatively small number of peers
out of 
	any single interface, especially if those peers are 'nearby'.  

	I agree.  I think that there some attention will need to be paid
how
	this is configured or setup.  Just plugging things in and not
paying
	attention to how things are setup or configured will cause
problems
	with UDP & TCP.  I guess some additional considerations will
need
	to be paid when running SCTP with respect how you interconnect
	multiple (multihomed) nodes together.

	John

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 24 Oct 2005 11:13:58 +0100

hi john,

could you be a bit more explicit about what sort of problems
you think could occur? my view is that unless an implementor
works hard to break things, 'plug & hope' should lead to a
success in *any* scenario. (here, 'works hard' means something
like binding to specific ports in the Querying node and setting
those ports up to be re-used, neither of which one sees in 
normal socket code. it would also lead just to a set of runtime
errors rather than an incorrect GIST configuration.) i would
expect the same reasoning to apply to any transport protocol.

there is however an issue if nodes attempt to economise on the number
of messaging associations by retaining a single one where several
have been set up with the same authenticated identity. at the
moment the spec says you MAY do this but doesn't indicate how
each end agrees this should be done (if one end doesn't agree,
some validation checks will fail and messages will be rejected.)
I lean towards a MUST or MUST NOT here, with updates to the 
text on validation in the former case.

robert h.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 21 October 2005 07:59
> To: Hancock, Robert; [email-masked]; [email-masked]
> 	I agree.  I think that there some attention will need 
> to be paid how
> 	this is configured or setup.  Just plugging things in 
> and not paying
> 	attention to how things are setup or configured will 
> cause problems
> 	with UDP & TCP.  I guess some additional considerations 
> will need