Subject: Re: [Taps] new draft available: draft-fairhurst-taps-transports-00

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 3 Nov 2014 13:56:30 +0100

Hi,

Thanks a lot for a good start.

I notice that MPTCP is quoted as a transport protocol but that CMT-SCTP
isn’t. I assume that this

is motivated by the fact that the taps work very clearly draws the line in
between

features that have made it through IETF standardisation (even as
informational)  and features that have not and

only are specified in “seemingly dormant” individual drafts. Correct ?

In terms of SCTP and the transport service that it provides, then I wonder
if the priority feature that it embeds is something

that afford special mentioning in this document. I.e., by usage of streams
and priority settings on streams then it is possible

to enforce that messages written on particular stream is able to outrace
messages written on other non-prioritized streams at least from a

sender transmittal perspective.

The feature is actually started to be deployed for some applications in
present signalling networks but it is only partially standardized in that
the

tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature are
not finished yet. Still the features are described in standards track
documents.

Thanks

BR, Karen

*From:* Taps [mailto:[email-masked]] *On Behalf Of *Aaron Falk
*Sent:* Tuesday, October 28, 2014 5:04 PM
*To:* [email-masked]
*Cc:* Gorry Fairhurst; Brian Trammell
*Subject:* [Taps] new draft available: draft-fairhurst-taps-transports-00

Hi Folks-

Gorry & Brian have published an annotated framework for TAPS doc 1 on
transport services here
<http://tools.ietf.org/html/draft-fairhurst-taps-transports-00>.  We'll
discuss whether to adopt it as a working group doc in Honolulu.  I
encourage you to send comments and offers to contribute text before then.

--aaron

---

From: Brian Trammell <[email-masked]>
Date: Mon, 3 Nov 2014 15:10:12 +0100

> On 03 Nov 2014, at 13:56, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi,
>  
> I notice that MPTCP is quoted as a transport protocol but that CMT-SCTP isn’t. I assume that this 
> is motivated by the fact that the taps work very clearly draws the line in between 
> features that have made it through IETF standardisation (even as informational)  and features that have not and

This is the intention (in keeping with item 1 on the charter). However, _this_ revision is very -00 and as such has only the most obvious things we could think of just before the deadline. My personal opinion is that if we can illustrate an interesting transport service using a proposed extension to an IETF protocol, then by all means let’s do so. 

> In terms of SCTP and the transport service that it provides, then I wonder if the priority feature that it embeds is something
> that afford special mentioning in this document. I.e., by usage of streams and priority settings on streams then it is possible
> to enforce that messages written on particular stream is able to outrace messages written on other non-prioritized streams at least from a 
> The feature is actually started to be deployed for some applications in present signalling networks but it is only partially standardized in that the
> tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature are not finished yet. Still the features are described in standards track documents.

This definitely seems to be a transport service of interest. 

Cheers,

Brian

> From: Taps [mailto:[email-masked]] On Behalf Of Aaron Falk
> Sent: Tuesday, October 28, 2014 5:04 PM
> To: [email-masked]
> Cc: Gorry Fairhurst; Brian Trammell
> Subject: [Taps] new draft available: draft-fairhurst-taps-transports-00
>  
> Hi Folks-
>  
> Gorry & Brian have published an annotated framework for TAPS doc 1 on transport services here.  We'll discuss whether to adopt it as a working group doc in Honolulu.  I encourage you to send comments and offers to contribute text before then.  
>  
> --aaron

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 3 Nov 2014 18:02:31 +0000

I thin kwe are going to face a lot of "extensions". Maybe a secondary goal could be to define a standard way to access both IETF and "extension" transports?

/mjm
Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Nov 3, 2014, at 9:10 AM, Brian Trammell <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: [email-masked]
Date: Mon, 3 Nov 2014 18:21:03 -0000

See a few comments in-line on various things.

> I thin kwe are going to face a lot of "extensions". Maybe a secondary goal
> could be to define a standard way to access both IETF and "extension"
> transports?
>
I think this may well be the case in the end, although there is still some
way to go before we reach that.  To me, the most important next step is we
recognise common terminology and therefore can make progress getting the
basic language correct.

+1 with Brian, if we agree the basics we could then consider other
protocols around this - there could be many that potentially could be
considered.

Gorry

>> This is the intention (in keeping with item 1 on the charter). However,
>> _this_ revision is very -00 and as such has only the most obvious things
>> we could think of just before the deadline. My personal opinion is that
>> if we can illustrate an interesting transport service using a proposed
>> extension to an IETF protocol, then by all means let’s do so.
>>
>>> In terms of SCTP and the transport service that it provides, then I
>>> wonder if the priority feature that it embeds is something
>>> that afford special mentioning in this document. I.e., by usage of
>>> streams and priority settings on streams then it is possible
>>> to enforce that messages written on particular stream is able to
>>> outrace messages written on other non-prioritized streams at least from
>>> a
>>> present signalling networks but it is only partially standardized in
>>> that the
>>> tsvwg documents (ndata, secondary SCTP-pr) that specifies the feature
>>> are not finished yet. Still the features are described in standards
>>> track documents.
>>
>>> transport services here.  We'll discuss whether to adopt it as a
>>> working group doc in Honolulu.  I encourage you to send comments and
>>> offers to contribute text before then.
>>>
>>> --aaron
>>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Nov 2014 19:49:57 +0100

On 03 Nov 2014, at 15:10, Brian Trammell <[email-masked]> wrote:

> This is the intention (in keeping with item 1 on the charter). However, _this_ revision is very -00 and as such has only the most obvious things we could think of just before the deadline. My personal opinion is that if we can 
The main reason which the SCTP CMT ID is still very -00 is based on the limited
chances that it will progress to an RFC. This might change in the future, but
the last time I tried it was hard to find people willing to implement it.
It is currently implemented in FreeBSD and two simulation models (NS-2 and INET for OMNeT++),
and most of the people involved are coauthors. So it is hard to get consumers of a potential
RFC. Maybe someone implementing it in Linux and Solaris...

Best regards
Michael
> illustrate an interesting transport service using a proposed extension to an IETF protocol, then by all means let’s do so. 
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 11 Nov 2014 11:26:34 +0100

> Gorry & Brian have published an annotated framework for TAPS doc 1 on transport services here.  We'll discuss whether to adopt it as a working group doc in Honolulu.  I encourage you to send commen…
Dear all,

I read the document and think it is a good starting point. I would support to adopt this
as a WG item. I'm willing to contribute to the document, for example by writing text
regarding SCTP (currently section 3.2) and helping to improve the text in other sections.

Best regards
Michael

---

From: Aaron Falk <[email-masked]>
Date: Tue, 11 Nov 2014 05:27:20 -0500

Thanks, Michael!!

On Tue, Nov 11, 2014 at 5:26 AM, Michael Tuexen <[email-masked]>
wrote:

> transport services here.  We'll discuss whether to adopt it as a working
> group doc in Honolulu.  I encourage you to send comments and offers to
> contribute text before then.
> Dear all,
>

---

From: [email-masked]
Date: Tue, 11 Nov 2014 12:24:25 -0000

Thanks Michael,

This offer is good and welcome - we need help to complete the sections.

Gorry