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

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 16 Oct 2005 18:38:12 +0100

hi,

a very interesting draft. i'm glad to see that SCTP can be
added to GIST with such a small draft ;-)

some comments

(trivial)
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.)

(non-trivial)
3.3: i didn't really understand this section. multi-homing 
(or any multi-interface) issues have their impact in D mode
only (in fact, query mode messages and NLI payloads), which
are unchanged; the linkage to MAs is done by cookie matching,
which is also unchanged. so I don't see why the fact that the
MA can use a multi-homing transport protocol should make any
difference.

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.

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Xiaoming Fu
> Sent: 16 October 2005 17:51
> To: [email-masked]
> Cc: Jon Crowcroft
> Subject: [NSIS] new draft "GIST over SCTP" and some comments to GIST
> 
> 
> 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-sc
tp/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
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 17 Oct 2005 10:39:35 +0200

> MA can use a multi-homing transport protocol should make any

I think there might be two issues here:
- only two end hosts are multihoming. This can have impact on how the 
MRIs are maintained, using which IP info in MRM of query messages and 
how to update the MRIs when a primary IP is changed from one to another.
- 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.
Xiaoming

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 17 Oct 2005 11:52:47 +0100

thanks for comments - yes, we need more tech detail in the draft -
thats why its only a draft:)

i take your point on APIs.
In missive <[email-masked]>, "Hancock, Rober
t" typed:

 >>This is a multi-part message in MIME format.
 >>
 >>------_=_NextPart_001_01C5D279.05328580
 >>Content-Type: text/plain;
 >>	charset="iso-8859-1"
 >>Content-Transfer-Encoding: quoted-printable
 >>
 >>hi,
 >>
 >>3.3: i didn't really understand this section. multi-homing=20
 >>proposes - it describes how to map SCTP features on to the=20
 >>> From: [email-masked] [mailto:[email-masked]] On=20
 >>> Behalf Of Xiaoming Fu
 >>>=20
 >>>=20
 >>>=20
 >>> We have submitted a new Internet draft on running GIST over=20
 >>> SCTP, with=20
 >>> the following abstract:
 >>>=20
 >>> Abstract:
 >>>     The General Internet Signaling Transport (GIST) protocol=20
 >>> currently=20
 >>> uses TCP or TLS over TCP for connection mode operation.  This=20
 >>> document=20
 >>> describes the usage of GIST over the Stream Control Transmission=20
 >>> Protocol (SCTP). The use of SCTP can take the advantage of features=20
 >>> provided by SCTP, namely streaming-based transport, support=20
 >>> of multiple=20
 >>> streams to avoid head of line blocking, and the support of=20
 >>> multi-homing=20
 >>> to provide network level fault tolerance. Additionally, the=20
 >>> support for=20
 >>> some extensions of SCTP is also discussed, namely its Partial=20
 >>>=20
 >>> Before it appears in IETF I-D repository, you can find it in the=20
 >>> following URL:=20
 >>We have also performed a prototype implementation for the basic SCTP=20
 >>support in GIST which we plan to include in the next release. In=20
 >>addition, we would like to point to some observations/questions about=20
 >>GIST thru this work:
 >>- Multi-homing: our analysis show that any multi-homing scenario (e.g.,=20
 >>host multihoming or AS level multihoming) may involve non-marginal=20
 >>consideration in GIST level state management and likely additional=20
 >>objects or readapted Stack-Proposal/Stack-Config-Data may be necessary.=20
 >>- API: should Transfer Attribute be constrained to only two values=20
 >>(Reliability, Unreliability)? What if the NSLP requires partial=20
 >>- In general, what if the two GIST peers do support a same type of=20
 >>transport mechanism, but not the same protocol version (e.g., TLS1.0=20
 >>v.s. 1.1, TCP with Reno v.s. with NewReno, as well as above-mentioned=20
 >>------_=_NextPart_001_01C5D279.05328580
 >>Content-Type: text/html;
 >>	charset="iso-8859-1"
 >>Content-Transfer-Encoding: quoted-printable
 >>
 >><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 >><HTML>
 >><HEAD>
 >><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
 >>charset=3Diso-8859-1">
 >><META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 >>6.5.7232.11">
 >><TITLE>RE: [NSIS] new draft &quot;GIST over SCTP&quot; and some comments =
 >>to GIST</TITLE>
 >></HEAD>
 >><BODY>
 >><!-- Converted from text/plain format -->
 >>
 >><P><FONT SIZE=3D2>hi,</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>a very interesting draft. i'm glad to see that SCTP =
 >>can be</FONT>
 >>
 >><BR><FONT SIZE=3D2>added to GIST with such a small draft ;-)</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>some comments</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>(trivial)</FONT>
 >>
 >><BR><FONT SIZE=3D2>in 3.1: IIRC the order of layered proposals is =
 >>top-&gt;bottom,</FONT>
 >>
 >><BR><FONT SIZE=3D2>i.e. the other way round. (there is discussion of =
 >>that at</FONT>
 >>
 >><BR><FONT SIZE=3D2><A =
 >>HREF=3D"http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue=
 >>68">http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68</=
 >>A>.)</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>(non-trivial)</FONT>
 >>
 >><BR><FONT SIZE=3D2>3.3: i didn't really understand this section. =
 >>multi-homing </FONT>
 >>
 >><BR><FONT SIZE=3D2>(or any multi-interface) issues have their impact in =
 >>D mode</FONT>
 >>
 >><BR><FONT SIZE=3D2>only (in fact, query mode messages and NLI payloads), =
 >>which</FONT>
 >>
 >><BR><FONT SIZE=3D2>are unchanged; the linkage to MAs is done by cookie =
 >>matching,</FONT>
 >>
 >><BR><FONT SIZE=3D2>which is also unchanged. so I don't see why the fact =
 >>that the</FONT>
 >>
 >><BR><FONT SIZE=3D2>MA can use a multi-homing transport protocol should =
 >>make any</FONT>
 >>
 >><BR><FONT SIZE=3D2>difference.</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>3.4.1: one of the fundamental goals of the API is =
 >>precisely</FONT>
 >>
 >><BR><FONT SIZE=3D2>that it should *not* change to allow the use of SCTP. =
 >>(this</FONT>
 >>
 >><BR><FONT SIZE=3D2>was extensively discussed at the 2004 interim and was =
 >>stated</FONT>
 >>
 >><BR><FONT SIZE=3D2>as a goal in the spec.) so it's unclear what API =
 >>changes should</FONT>
 >>
 >><BR><FONT SIZE=3D2>be needed. But in fact, I can't tell what changes =
 >>3.4.1 actually</FONT>
 >>
 >><BR><FONT SIZE=3D2>proposes - it describes how to map SCTP features on =
 >>to the </FONT>
 >>
 >><BR><FONT SIZE=3D2>API (which is reasonable), but the API itself seems =
 >>unchanged.</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>cheers,</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>robert h.</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
 >>HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
 >>On </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Behalf Of Xiaoming Fu</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Sent: 16 October 2005 17:51</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Cc: Jon Crowcroft</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Subject: [NSIS] new draft &quot;GIST over =
 >>SCTP&quot; and some comments to GIST</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Hi all,</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; We have submitted a new Internet draft on =
 >>running GIST over </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; SCTP, with </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; the following abstract:</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Abstract:</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The General Internet =
 >>Signaling Transport (GIST) protocol </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; currently </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; uses TCP or TLS over TCP for connection mode =
 >>operation.&nbsp; This </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; document </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; describes the usage of GIST over the Stream =
 >>Control Transmission </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Protocol (SCTP). The use of SCTP can take the =
 >>advantage of features </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; provided by SCTP, namely streaming-based =
 >>transport, support </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; of multiple </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; streams to avoid head of line blocking, and the =
 >>support of </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; multi-homing </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; to provide network level fault tolerance. =
 >>Additionally, the </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; support for </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; some extensions of SCTP is also discussed, =
 >>namely its Partial </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Reliability Extension and the usage of TLS over =
 >>SCTP.</FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; Before it appears in IETF I-D repository, you =
 >>can find it in the </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; following URL: </FONT>
 >>
 >><BR><FONT SIZE=3D2>&gt; <A =
 >>HREF=3D"http://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc">h=
 >>ttp://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc</A></FONT>
 >>
 >><BR><FONT SIZE=3D2>tp/draft-fu-nsis-ntlp-sctp-00.txt</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>We would appreciate it if you would review and comment =
 >>on the draft.</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>We have also performed a prototype implementation for =
 >>the basic SCTP </FONT>
 >>
 >><BR><FONT SIZE=3D2>support in GIST which we plan to include in the next =
 >>release. In </FONT>
 >>
 >><BR><FONT SIZE=3D2>addition, we would like to point to some =
 >>observations/questions about </FONT>
 >>
 >><BR><FONT SIZE=3D2>GIST thru this work:</FONT>
 >>
 >><BR><FONT SIZE=3D2>- Multi-homing: our analysis show that any =
 >>multi-homing scenario (e.g., </FONT>
 >>
 >><BR><FONT SIZE=3D2>host multihoming or AS level multihoming) may involve =
 >>non-marginal </FONT>
 >>
 >><BR><FONT SIZE=3D2>consideration in GIST level state management and =
 >>likely additional </FONT>
 >>
 >><BR><FONT SIZE=3D2>objects or readapted Stack-Proposal/Stack-Config-Data =
 >>may be necessary. </FONT>
 >>
 >><BR><FONT SIZE=3D2>See some preliminary discussions in Section =
 >>3.4.</FONT>
 >>
 >><BR><FONT SIZE=3D2>- API: should Transfer Attribute be constrained to =
 >>only two values </FONT>
 >>
 >><BR><FONT SIZE=3D2>(Reliability, Unreliability)? What if the NSLP =
 >>requires partial </FONT>
 >>
 >><BR><FONT SIZE=3D2>reliability? See more discussions in Section 3.4.1 in =
 >>this I-D.</FONT>
 >>
 >><BR><FONT SIZE=3D2>- In general, what if the two GIST peers do support a =
 >>same type of </FONT>
 >>
 >><BR><FONT SIZE=3D2>transport mechanism, but not the same protocol =
 >>version (e.g., TLS1.0 </FONT>
 >>
 >><BR><FONT SIZE=3D2>v.s. 1.1, TCP with Reno v.s. with NewReno, as well as =
 >>above-mentioned </FONT>
 >>
 >><BR><FONT SIZE=3D2>standard SCTP v.s. PR-SCTP, and so on).</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>Thanks,</FONT>
 >>
 >><BR><FONT SIZE=3D2>Xiaoming</FONT>
 >></P>
 >>
 >><P><FONT SIZE=3D2>_______________________________________________</FONT>
 >>
 >><BR><FONT SIZE=3D2>nsis mailing list</FONT>
 >>
 >><BR><FONT SIZE=3D2>[email-masked]</FONT>
 >>
 >><BR><FONT SIZE=3D2><A =
 >>HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.or=
 >>g/mailman/listinfo/nsis</A></FONT>
 >></P>
 >>
 >></BODY>
 >></HTML>
 >>------_=_NextPart_001_01C5D279.05328580--

 cheers

   jon