Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.txt

From: Simone Ferlin-Oliveira <[email-masked]>
Date: Thu, 5 Mar 2015 13:10:51 +1100

Greetings,

Sections 3.2 and 3.3 in draft-03 remind us that there are
commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They
could be further summarised, perhaps in a dedicated session to
“multi-path features”, abstracting what both protocols provide to
applications. It could be, for example, inside section 4 as
subsection.

If the group agrees with that, we would like to take it (Section 4) as
contributors.

Thanks,
Simone Ferlin and Olivier Mehani

On 27 February 2015 at 23:58, Brian Trammell <[email-masked]> wrote:
> Greetings, all,
>
> We've posted rev -03 of the taps-transports document; this includes a new Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP by Kevin Fall; thanks Michael and Kevin!
>
> Comments on the new sections or the structure thereof (i.e., as input to future transport protocol sections), or indeed on anything else in the document, are very welcome. :)
>
> Thanks, cheers,
>
> Brian
>
>> Begin forwarded message:
>>
>> From: [email-masked]
>> To: "Gorry Fairhurst" <[email-masked]>, "Mirja Kuehlewind" <[email-masked]>, "Brian Trammell" <[email-masked]>, "Mirja Kuehlewind" <[email-masked]>, "Godred Fairhurst" <[email-masked]>, "Brian Trammell" <[email-masked]>
>> Subject: New Version Notification for draft-ietf-taps-transports-03.txt
>> Date: 27 Feb 2015 13:52:23 CET
>>
>>
>> A new version of I-D, draft-ietf-taps-transports-03.txt
>> has been successfully submitted by Brian Trammell and posted to the
>> IETF repository.
>>
>> Name:         draft-ietf-taps-transports
>> Revision:     03
>> Title:                Services provided by IETF transport protocols and congestion control mechanisms
>> Document date:        2015-02-27
>> Group:                taps
>> Pages:                25
>> URL:            http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-taps-transports/
>> Htmlized:       http://tools.ietf.org/html/draft-ietf-taps-transports-03
>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03
>>
>> Abstract:
>>   This document describes services provided by existing IETF protocols
>>   and congestion control mechanisms.  It is designed to help
>>   application and network stack programmers and to inform the work of
>>   the IETF TAPS Working Group.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Mar 2015 20:15:51 -0800

> applications. It could be, for example, inside section 4 as

These are multi-endpoint features. Despite the name of MPTCP and the
fact that this has been pointed out repeatedly to them, let's please not
continue to mislabel this as multi-path.

Joe

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Mar 2015 11:09:29 +0100

hi Simone,

> On 05 Mar 2015, at 03:10, Simone Ferlin-Oliveira <[email-masked]> wrote:
> 
> Greetings,
> 

Modulo Joe's comment that we shouldn't confuse "multi-path" (which is the goal...), "multi-endpoint" (...the abstraction we can use at the endpoints to try to meet the goal...), and "multi-interface" (...and the implementation of the abstraction) when defining a terminology here, this sounds good to me.

> If the group agrees with that, we would like to take it (Section 4) as

Thanks!

Cheers,

Brian

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 05 Mar 2015 12:23:21 +0100

Hi Simone,

thanks for this offer. The idea of this document is to first describe all 
existing protocols separately and then based on these descriptions detect common 
transport service features. And, this might be again a terminology issues, this 
is not about the API that is exposed to the higher layer but rather about the 
actual feature that are implemented below.

I see this the following way: the reason for writing this document is not that 
someone can later read a nice summary about existing IETF (transport) protocol 
but it about the group doing the exercise to make sure that we don't missing 
something just because we all believe we are expert anyway...

Having said this, I'd like to first see a complete section (3.2) on MPTCP before 
we start to writing something on this in section 4. However, I'm sure you could 
also help to provide some text in section 3.2...? That would be great!

Mirja

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: [email-masked]
------------------------------------------

---

From: Olivier Mehani <[email-masked]>
Date: Fri, 6 Mar 2015 10:33:29 +1100

Hi Mirja, all,

On Thu, Mar 05, 2015 at 12:23:21PM +0100, Mirja Kühlewind wrote:
> existing protocols separately and then based on these descriptions detect
> common transport service features. And, this might be again a terminology
> issues, this is not about the API that is exposed to the higher layer but
> rather about the actual feature that are implemented below.
> 
> Having said this, I'd like to first see a complete section (3.2) on MPTCP
> before we start to writing something on this in section 4. However, I'm sure
> you could also help to provide some text in section 3.2...? That would be
> great!

Yes, that was the plan. I think the API for both SCTP and MPTCP are
relevant in highlighting the underlying features of the protocol, even
though these APIs are not what needs to be described.

The synthesis in section 4 should come at a later stage, once 3.2 (and
perhaps a similar discussion in SCTP's section), have been written up.

-- 
Olivier Mehani <[email-masked]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 06 Mar 2015 11:25:35 +0100

Hi Olivier,

see below

> though these APIs are not what needs to be described.

Yep. APIs should not be discussed in section 4. However, for the protocol 
description in section 3, if you look at the other descriptions, there is also a 
subsection on the (higher layer) interface. As you say there is often a strong 
dependency therefore I think there is a purpose to describe the interface as 
well (in section 3) to have a ground truth for discussion.

> perhaps a similar discussion in SCTP's section), have been written up.

Yes!

Mirja

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 16 Mar 2015 12:52:37 +0100

Hi Mirja,

>>>
>>> Having said this, I'd like to first see a complete section (3.2) on
>>> MPTCP before we start to writing something on this in section 4.
>>> However, I'm sure you could also help to provide some text in section
>>> 3.2...? That would be great!
>>
[Karen ] Do you here refer to SCTP MH or CMT SCTP ?

MPTCP include concurrency aspects which, for SCTP, only significantly
arise with CMT SCTP.

It has previously been stated that CMT SCTP would not be in scope of taps.
Is that still the assumption ?

BR, Karen

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 16 Mar 2015 14:07:17 +0100

Hi Karen,

section 3 should describe what currently is standardized. Am I right that there is no RFC on CMT SCTP (yet)… and that this was/is the reason that there was some discussion that this is out of scope? If so, what the status of CMT SCTP? Will there be potentially be an RFC anytime soon?

However, in section 3 if there are any similarities to MPTCP in SCTP, either in MH or CMT, these could be described in a similar way and potentially even refer to MPTCP or the other way around. If SCTP is described independent of MPTCP that’s fine as well, or potentially even better for the start. As soon as we then start writing section 4, we anyway to have to detect those similarities and can still add references or adapt the wording to use the same term later on.

Mirja

> Am 16.03.2015 um 12:52 schrieb Karen Elisabeth Egede Nielsen <[email-masked]>:
> 
> Hi Mirja,
> 
>>>>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 16 Mar 2015 14:22:03 +0100

> On 16 Mar 2015, at 14:07, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Karen,
> 
Hi Mirja,

this is an interesting question. It is not yet a WG document and the last time I asked
for WG adoption, the question by the chairs was who would the consumer of the document
be? A lot of people involved in implementing this in FreeBSD, the ns-2 and the INET
simulator are already co-authors.
I tried to get some support for stack vendors, but none of them wanted to make statements
about future products.

If there is a chance to progress this in TSVWG as a WG document, we would be interested,
but I don't see why I should get a different answer when asking the same question again
without having a relevant list of some "consumers" of the potential RFC.

Best regards
Michael

---

From: [email-masked]
Date: Mon, 16 Mar 2015 13:41:42 -0000

See below

> Is that still the assumption ?

I think SCTP multihoming and path failover should be there.

I personally think that formal discussion of SCTP/ CMT falls outside the
scope of TAPS, until the IETF decides to adopt this work (that's for TSVWG
sometime). However, I guess if TAPS wanted to refer to a paper on the
possibility of such extensions to SCTP in the discussion section that
could easily be considered.

Gorry

---

From: [email-masked]
Date: Mon, 16 Mar 2015 14:04:43 -0000

Se below
>> section 3 should describe what currently is standardized. Am I right
>> that there is no RFC on CMT SCTP (yet)… and that this was/is the
>> reason that there was some discussion that this is out of scope? If so,
>> what the status of CMT SCTP? Will there be potentially be an RFC anytime
>> soon?
> Hi Mirja,
>

As tswg co-chair: that is more or less what I recall.

Importantly: There was no decision that this was outside the charter. So,
if there are developments or indications of greater maturity, then tsvwg
could revisit this and revive the work - but I'd expect the same questions
to be asked by the Chairs.

Gorry (with tsvwg chair hat upon my head)

>>
>> However, in section 3 if there are any similarities to MPTCP in SCTP,
>> either in MH or CMT, these could be described in a similar way and
>> potentially even refer to MPTCP or the other way around. If SCTP is
>> described independent of MPTCP that’s fine as well, or potentially
>> even better for the start. As soon as we then start writing section 4,
>> we anyway to have to detect those similarities and can still add
>> references or adapt the wording to use the same term later on.
>>
>> Mirja
>>
>>
>>
>>>> description in section 3, if you look at the other descriptions, there
>>>> is
>>> also a
>>>> subsection on the (higher layer) interface. As you say there is often
>>>> a
>>> strong
>>>> dependency therefore I think there is a purpose to describe the
>>>> interface
>>> as

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 16 Mar 2015 21:40:01 +0100

HI,

See below.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, March 16, 2015 2:42 PM
>To: Karen Elisabeth Egede Nielsen
>Cc: "Mirja Kühlewind"; Olivier Mehani; Simone Ferlin-Oliveira; taps WG
>Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-
>transports-03.txt
>
>See below
>
>> Hi Mirja,
>>
>>>>>
>>>>> However, I'm sure you could also help to provide some text in
>>>>> section 3.2...? That would be great!
>>>>
>>>> relevant in highlighting the underlying features of the protocol,
>>>> even though these APIs are not what needs to be described.
>>>
>>>Yep. APIs should not be discussed in section 4. However, for the
>>>protocol description in section 3, if you look at the other
>>>descriptions, there is
>> also a
>>>> The synthesis in section 4 should come at a later stage, once 3.2
>>>> (and perhaps a similar discussion in SCTP's section), have been
written up.
>I personally think that formal discussion of SCTP/ CMT falls outside the
scope
>of TAPS, until the IETF decides to adopt this work (that's for TSVWG
could
>easily be considered.
[Karen ] I would definitively support that such references be made.
Provided, of course, that
such becomes relevant and meaningful in the context of Multi Path
discussions in taps.

I agree that we still have to wait and see for when CMT-SCTP makes it to
the top of things to progress in tsvwg.

BR, Karen