Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-28 Thread Karen Elisabeth Egede Nielsen 
Hi,

Thanks.

If this was not clear, then I should emphasize that
I think this document is an excellent starting point !

BR, Karen

> -Original Message-
> From: Michael Welzl [mailto:mich...@ifi.uio.no]
> Sent: 27. oktober 2015 15:07
> To: Karen Elisabeth Egede Nielsen
> Cc: taps@ietf.org
> Subject: Re: [Taps] New Version Notification for
> draft-welzl-taps-transports-
> 00.txt
>
> Dear Karen,
>
> Thanks a lot for your comments!
> This was only meant as a starting point - e.g. the decision to only use
> RFC4960
> but not RFC6458 is definitely not set in stone.
>
> We’ll incorporate them in the next revision (and then maybe get back to
> you
> in case we need discussion) - thanks again!
>
> Cheers,
> Michael
>
>
> > On 27. okt. 2015, at 14.58, Karen Elisabeth Egede Nielsen
>  wrote:
> >
> > HI,
> >
> > FWIIW please accept the following comments to the document:
> >
> > Section 3.1:
> >
> > "Passive open with fully specified foreign socket"
> >
> > Is that a typical function provided to ULP by TCP ?
> > Our POSIX socket api implementation does not really provide this. Or it
> > does by set of special filters on the
> > listening socket, but I wasn't aware that this was a feature generally
> > available in TCP.
> >
> > "Passive open with fully specified foreign socket" on a unspecified
> > passive open socket ?
> >
> > I assume we speak listening socket. Again is this something typically
> > provided as an option to ULP by TCP ?
> >
> > "Send: and PUSH flag description":
> >
> > The PUSH flag is typically set inside the TCP implementation and the ULP
> > typically has no direct influence on the setting of it. I think that it
> > is
> > strange that this function
> > is chosen to be described as if it is controlled directly by ULP when it
> > is indeed not.
> >
> > There is some text later in section 3.1.1 motivating the choice. Yes it
> > is
> > correct that TCP implementations implement
> > set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches
> > that the PUSH flag is set in the end of a communication,
> > but again it is not controlled by ULP. As the intend of this document is
> > to expose services that the ULP
> > can invoke, I think that it is problematic that it is described as if
> > the
> > ULP can control PUSH directly, when it indeed (often) cannot.
> >
> > Section 3.2:
> >
> > General comment:
> >
> > The multi-stream capability and stream prioritization/scheduling
> > possibilities of SCTP is a feature
> > differentiating SCTP from TCP. The same is the fact that SCTP (SCTP-PR)
> > also provide unreliable (no retransmissions) and partial reliable
> > transport service (timeout).
> >
> > I think that these service features are important for certain SCTP
> > deployment scenarios
> > and that it would be desirable for these to be exposed here. (The
> > timeout
> > is described)
> > It not included here in the first pass it will never even get considered
> > for TAPS as a potential service, would it ?
> > (It might end up being excluding, but then this should be a
> > conscious (visible) choice, I think).
> >
> > Detailed comments:
> >
> > "Initialize needs be called only once per set of local addresses":
> >
> > This is the case when supporting one-to-many style sockets. Perhaps one
> > might add
> > "but ULP may also initialize each association endpoint instance
> > individually".
> >
> > "Associate":
> >
> > I think that it is relevant to clarify that the remote SCTP instance in
> > the association primitive is
> > identified by one or multiple destination addresses thus allowing also
> > the
> > association handshake
> > to proceed using multiple paths.
> >
> > "Send":
> >
> > "Another advisory flag indicates the ULP's preference to avoid bundling
> > user data .."
> >
> > This is specified as an optional attribute in RFC4960. This is not
> > specified in the RFC6458 socket API.
> > ((Yes it might be similar to the TCP PUSH flag in that it is not
> > generally
> > implemented as directly controllable by ULP on a message basis - Or?))
> >
> > Section 4.2:
> >
> > SCTP implements NO_delay (Nagle) option on a per association basis (as
> TCP
> > on a per connection basis) but not typically
> > on a per message basis as described here. There a

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-27 Thread Michael Welzl 
Dear Karen,

Thanks a lot for your comments!
This was only meant as a starting point - e.g. the decision to only use RFC4960 
but not RFC6458 is definitely not set in stone.

We’ll incorporate them in the next revision (and then maybe get back to you in 
case we need discussion) - thanks again!

Cheers,
Michael


> On 27. okt. 2015, at 14.58, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI,
> 
> FWIIW please accept the following comments to the document:
> 
> Section 3.1:
> 
> "Passive open with fully specified foreign socket"
> 
> Is that a typical function provided to ULP by TCP ?
> Our POSIX socket api implementation does not really provide this. Or it
> does by set of special filters on the
> listening socket, but I wasn't aware that this was a feature generally
> available in TCP.
> 
> "Passive open with fully specified foreign socket" on a unspecified
> passive open socket ?
> 
> I assume we speak listening socket. Again is this something typically
> provided as an option to ULP by TCP ?
> 
> "Send: and PUSH flag description":
> 
> The PUSH flag is typically set inside the TCP implementation and the ULP
> typically has no direct influence on the setting of it. I think that it is
> strange that this function
> is chosen to be described as if it is controlled directly by ULP when it
> is indeed not.
> 
> There is some text later in section 3.1.1 motivating the choice. Yes it is
> correct that TCP implementations implement
> set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches
> that the PUSH flag is set in the end of a communication,
> but again it is not controlled by ULP. As the intend of this document is
> to expose services that the ULP
> can invoke, I think that it is problematic that it is described as if the
> ULP can control PUSH directly, when it indeed (often) cannot.
> 
> Section 3.2:
> 
> General comment:
> 
> The multi-stream capability and stream prioritization/scheduling
> possibilities of SCTP is a feature
> differentiating SCTP from TCP. The same is the fact that SCTP (SCTP-PR)
> also provide unreliable (no retransmissions) and partial reliable
> transport service (timeout).
> 
> I think that these service features are important for certain SCTP
> deployment scenarios
> and that it would be desirable for these to be exposed here. (The timeout
> is described)
> It not included here in the first pass it will never even get considered
> for TAPS as a potential service, would it ?
> (It might end up being excluding, but then this should be a
> conscious (visible) choice, I think).
> 
> Detailed comments:
> 
> "Initialize needs be called only once per set of local addresses":
> 
> This is the case when supporting one-to-many style sockets. Perhaps one
> might add
> "but ULP may also initialize each association endpoint instance
> individually".
> 
> "Associate":
> 
> I think that it is relevant to clarify that the remote SCTP instance in
> the association primitive is
> identified by one or multiple destination addresses thus allowing also the
> association handshake
> to proceed using multiple paths.
> 
> "Send":
> 
> "Another advisory flag indicates the ULP's preference to avoid bundling
> user data .."
> 
> This is specified as an optional attribute in RFC4960. This is not
> specified in the RFC6458 socket API.
> ((Yes it might be similar to the TCP PUSH flag in that it is not generally
> implemented as directly controllable by ULP on a message basis - Or?))
> 
> Section 4.2:
> 
> SCTP implements NO_delay (Nagle) option on a per association basis (as TCP
> on a per connection basis) but not typically
> on a per message basis as described here. There are some additional
> bundling control related to stream scheduling - some are described in
> sctp-ndata draft.
> 
> Section 5.1:
> 
> "Disable Nagle algorithm:"
> 
> Not specified in RFC4960, but in RFC6458 for SCTP.
> Is it really valid to use RFC4960 as a reference for the socket API when
> the approach of
> SCTP IETF community has been to use RFC6458 for this ?
> 
> ***
> 
> BR, Karen
> 
> 
> 
>> -Original Message-
>> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Michael Welzl
>> Sent: 21. september 2015 10:45
>> To: taps WG
>> Subject: [Taps] Fwd: New Version Notification for draft-welzl-taps-
>> transports-00.txt
>> 
>> Dear all,
>> 
>> In my presentation in Prague, I proposed an approach to identify the
> services
>> that transport protocols provide. At the end of the ensuing discussion,
> I said
>> that I (with co-authors) would write a draft that explains the proposal
> by
>> applying the proposed method to TCP and SCTP.
>> 
>> We just submitted this document - see below;  I hope that this will lead
> to
>> some discussion on the list...
>> 
>> Cheers,
>> Michael
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: 
>>> Subject: New Version Notification for
>>> draft-welzl-taps-transports-00.txt
>>> Date: 21 Sep 2015 10:35:33 CEST
>>> To: Michael Welzl , Michael Welzl
>>> , Michael Tuexen ,
>> Naeem

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-23 Thread Joe Touch 
+1

I have read this version in detail (and provided feedback), and think it
is a useful document.

Joe

On 10/5/2015 12:49 PM, Brian Trammell wrote:
> In transit, please excuse the brevity.
> 
> Broadly I appreciate the effort to do the decomposition in a less
> arbitrary way. I'm not convinced it's actually less arbitrary, but this
> is largely irrelevant: it's a *different* way to do the decomposition,
> so points of agreement (of which, at least on TCP and SCTP, there are
> many) reinforce confidence that we're doing this right. I tend to agree
> with Gorry's suggestion on the way forward.
> 
> Cheers, Brian
> 
> Sent from my iPhone
> 
> On 05 Oct 2015, at 11:42, Aaron Falk  > wrote:
> 
>> Have others read this draft yet?   It is clearly aimed at addressing
>> charter deliverable #1.  Do other folks have an opinion on how well it
>> helps the group achieve the goals in our charter?  Should we use this
>> document in some way? I'm looking for more input from the working
>> group on how we should proceed. 
>>
>> My opinion: I am very mindful (& appreciative) of the significant
>> effort by Mirja and Brian and the other contributors on
>> draft-ietf-taps-transports.The discussion around this doc has been
>> very useful for clarifying (to me) how difficult it can be to pull
>> useful common abstractions out of the 30+ years of transport
>> technologies.  Having been down this path for over a year, I
>> appreciate the fairly narrow approach draft-welzl-taps-transports and
>> think it may be the best chance for TAPS to succeed.  
>>
>> Please share your views.
>>
>> --aaron
>>
>>
>> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl > > wrote:
>>
>> +1
>>
>> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit
>> mailto:ma...@mjmontpetit.com>> wrote:
>> >
>> > Makes sense.
>> >
>> >> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk
>>  wrote:
>> >>
>> >> We seem to have two documents in a space where we started with
>> one. These
>> >> are different, to me this is OK. Both seem close to charter
>> milestone 1. I
>> >> don't see much overlap between the contents of the descriptive
>> language
>> >> and the API-focussed analysis, and any overlap could be eliminated.
>> >>
>> >> To me, doc 1 (current chartered item) can evolve to provide
>> background and
>> >> missing documentation for anyone in the IETF, and should compare
>> >> transports in a broad way and draw out the idea that they provide
>> >> services. This appears to be harder to get right than I for one
>> had hoped,
>> >> and still has a wide scope. Not a bad thing. I suggest it will
>> provide a
>> >> reference to stop us rat-holing when people ask what is "this"
>> and explain
>> >> how all these transports stack-up against one another (good
>> pun?). We can
>> >> (I suggest) finish this doc in this way.
>> >>
>> >> I do like the idea of a second document focussed ONLY on the
>> Transport API
>> >> (I'd call this 1a). In this we can avoid this"discussion of
>> what are
>> >> transports"  and move to  a  more focussed  process in doc 1b, 
>> Most of
>> >> that troublesome descriptive  text can go into 1, and ensure we
>> keep that
>> >> one readable to anyone in the  IETF.
>> >>
>> >> Could  I suggest the two docs against the first milestone will
>> help us
>> >> make  progress towards the next milestone faster. (Assuming we
>> can keep
>> >> the two aligned, which seems quite doable). I can see also how
>> the  docs
>> >> are useful to different people. I'd like to see both mature and
>> provide
>> >> inputs to move forward.
>> >>
>> >> Gorry
>> >>
>> >>
>> >>> Interesting and inline to getting transport API(s)
>> >>>
>> >>> Marie-José Montpetit
>> >>> ma...@mjmontpetit.com 
>> >>> mari...@mit.edu 
>> >>>
>>  On Sep 21, 2015, at 04:44, Michael Welzl > > wrote:
>> 
>>  Dear all,
>> 
>>  In my presentation in Prague, I proposed an approach to
>> identify the
>>  services that transport protocols provide. At the end of the
>> ensuing
>>  discussion, I said that I (with co-authors) would write a
>> draft that
>>  explains the proposal by applying the proposed method to TCP
>> and SCTP.
>> 
>>  We just submitted this document - see below;  I hope that
>> this will lead
>>  to some discussion on the list...
>> 
>>  Cheers,
>>  Michael
>> 
>> 
>> > Begin forwarded message:
>> >
>> > From: > >
>> > Subject: New Version Notification for
>>

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-07 Thread Brian Trammell 

> On 07 Oct 2015, at 09:17, Michael Welzl  wrote:
> 
> Hi,
> 
> 
>> On 05 Oct 2015, at 20:42, Aaron Falk  wrote:
>> 
>> Have others read this draft yet?   It is clearly aimed at addressing charter 
>> deliverable #1.  Do other folks have an opinion on how well it helps the 
>> group achieve the goals in our charter?  Should we use this document in some 
>> way? I'm looking for more input from the working group on how we should 
>> proceed.
>> 
>> My opinion: I am very mindful (& appreciative) of the significant effort by 
>> Mirja and Brian and the other contributors on draft-ietf-taps-transports.
> 
> +1
> 
> 
>>   The discussion around this doc has been very useful for clarifying (to me) 
>> how difficult it can be to pull useful common abstractions out of the 30+ 
>> years of transport technologies.  Having been down this path for over a 
>> year, I appreciate the fairly narrow approach draft-welzl-taps-transports 
>> and think it may be the best chance for TAPS to succeed.
>> 
>> Please share your views.
> 
> You say you appreciate the "fairly narrow" approach of 
> draft-welzl-taps-transports. This makes me wonder - maybe 
> draft-welzl-taps-transports should only cover a subset of the transports in 
> draft-ietf-taps-transports, based on what we can see in 
> draft-ietf-taps-transports?

Definitely. I think the "narrow" approach can work here -- the scope is already 
narrowed by only considering unicast services, which simplifies things quite a 
bit. The question is how and whether to narrow further. TCP (and MPTCP), UDP 
(and UTP-lite), and SCTP clearly make the cut, as they are widely deployed 
and/or there is active work on top of them for which we expect wide deployment. 
Others I'm less sure of.

Cheers,

Brian

> (e.g. the eventual text on RTP in draft-ietf-taps-transports will probably 
> not be a short list of features, which may indicate that RTP should not be 
> included in draft-welzl-taps-transports).
> 
> Cheers,
> Michael
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-07 Thread Michael Welzl 
Hi,


> On 05 Oct 2015, at 20:42, Aaron Falk  wrote:
> 
> Have others read this draft yet?   It is clearly aimed at addressing charter 
> deliverable #1.  Do other folks have an opinion on how well it helps the 
> group achieve the goals in our charter?  Should we use this document in some 
> way? I'm looking for more input from the working group on how we should 
> proceed. 
> 
> My opinion: I am very mindful (& appreciative) of the significant effort by 
> Mirja and Brian and the other contributors on draft-ietf-taps-transports.

+1


>The discussion around this doc has been very useful for clarifying (to me) 
> how difficult it can be to pull useful common abstractions out of the 30+ 
> years of transport technologies.  Having been down this path for over a year, 
> I appreciate the fairly narrow approach draft-welzl-taps-transports and think 
> it may be the best chance for TAPS to succeed.  
> 
> Please share your views.

You say you appreciate the "fairly narrow" approach of 
draft-welzl-taps-transports. This makes me wonder - maybe 
draft-welzl-taps-transports should only cover a subset of the transports in 
draft-ietf-taps-transports, based on what we can see in 
draft-ietf-taps-transports?   (e.g. the eventual text on RTP in 
draft-ietf-taps-transports will probably not be a short list of features, which 
may indicate that RTP should not be included in draft-welzl-taps-transports).

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-05 Thread Brian Trammell 
In transit, please excuse the brevity.

Broadly I appreciate the effort to do the decomposition in a less arbitrary 
way. I'm not convinced it's actually less arbitrary, but this is largely 
irrelevant: it's a *different* way to do the decomposition, so points of 
agreement (of which, at least on TCP and SCTP, there are many) reinforce 
confidence that we're doing this right. I tend to agree with Gorry's suggestion 
on the way forward.

Cheers, Brian

Sent from my iPhone

> On 05 Oct 2015, at 11:42, Aaron Falk  wrote:
> 
> Have others read this draft yet?   It is clearly aimed at addressing charter 
> deliverable #1.  Do other folks have an opinion on how well it helps the 
> group achieve the goals in our charter?  Should we use this document in some 
> way? I'm looking for more input from the working group on how we should 
> proceed. 
> 
> My opinion: I am very mindful (& appreciative) of the significant effort by 
> Mirja and Brian and the other contributors on draft-ietf-taps-transports.
> The discussion around this doc has been very useful for clarifying (to me) 
> how difficult it can be to pull useful common abstractions out of the 30+ 
> years of transport technologies.  Having been down this path for over a year, 
> I appreciate the fairly narrow approach draft-welzl-taps-transports and think 
> it may be the best chance for TAPS to succeed.  
> 
> Please share your views.
> 
> --aaron
> 
> 
>> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl  wrote:
>> +1
>> 
>> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit  
>> > wrote:
>> >
>> > Makes sense.
>> >
>> >> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk wrote:
>> >>
>> >> We seem to have two documents in a space where we started with one. These
>> >> are different, to me this is OK. Both seem close to charter milestone 1. I
>> >> don't see much overlap between the contents of the descriptive language
>> >> and the API-focussed analysis, and any overlap could be eliminated.
>> >>
>> >> To me, doc 1 (current chartered item) can evolve to provide background and
>> >> missing documentation for anyone in the IETF, and should compare
>> >> transports in a broad way and draw out the idea that they provide
>> >> services. This appears to be harder to get right than I for one had hoped,
>> >> and still has a wide scope. Not a bad thing. I suggest it will provide a
>> >> reference to stop us rat-holing when people ask what is "this" and explain
>> >> how all these transports stack-up against one another (good pun?). We can
>> >> (I suggest) finish this doc in this way.
>> >>
>> >> I do like the idea of a second document focussed ONLY on the Transport API
>> >> (I'd call this 1a). In this we can avoid this"discussion of what are
>> >> transports"  and move to  a  more focussed  process in doc 1b,  Most of
>> >> that troublesome descriptive  text can go into 1, and ensure we keep that
>> >> one readable to anyone in the  IETF.
>> >>
>> >> Could  I suggest the two docs against the first milestone will help us
>> >> make  progress towards the next milestone faster. (Assuming we can keep
>> >> the two aligned, which seems quite doable). I can see also how the  docs
>> >> are useful to different people. I'd like to see both mature and provide
>> >> inputs to move forward.
>> >>
>> >> Gorry
>> >>
>> >>
>> >>> Interesting and inline to getting transport API(s)
>> >>>
>> >>> Marie-José Montpetit
>> >>> ma...@mjmontpetit.com
>> >>> mari...@mit.edu
>> >>>
>>  On Sep 21, 2015, at 04:44, Michael Welzl  wrote:
>> 
>>  Dear all,
>> 
>>  In my presentation in Prague, I proposed an approach to identify the
>>  services that transport protocols provide. At the end of the ensuing
>>  discussion, I said that I (with co-authors) would write a draft that
>>  explains the proposal by applying the proposed method to TCP and SCTP.
>> 
>>  We just submitted this document - see below;  I hope that this will lead
>>  to some discussion on the list...
>> 
>>  Cheers,
>>  Michael
>> 
>> 
>> > Begin forwarded message:
>> >
>> > From: 
>> > Subject: New Version Notification for
>> > draft-welzl-taps-transports-00.txt
>> > Date: 21 Sep 2015 10:35:33 CEST
>> > To: Michael Welzl , Michael Welzl
>> > , Michael Tuexen , Naeem
>> > Khademi , Michael Tuexen ,
>> > Naeem Khademi 
>> > Resent-From: 
>> >
>> >
>> > A new version of I-D, draft-welzl-taps-transports-00.txt
>> > has been successfully submitted by Michael Welzl and posted to the
>> > IETF repository.
>> >
>> > Name:draft-welzl-taps-transports
>> > Revision:00
>> > Title:An Approach to Identify Services Provided by IETF
>> > Transport Protocols and Congestion Control Mechanisms
>> > Document date:2015-09-21
>> > Group:Individual Submission
>> > Pages:23
>> > URL:
>> > https://www.ietf.org/internet-drafts/draft-welzl-taps-

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-10-05 Thread Aaron Falk 
Have others read this draft yet?   It is clearly aimed at addressing
charter deliverable #1.  Do other folks have an opinion on how well it
helps the group achieve the goals in our charter?  Should we use this
document in some way? I'm looking for more input from the working group on
how we should proceed.

My opinion: I am very mindful (& appreciative) of the significant effort by
Mirja and Brian and the other contributors on draft-ietf-taps-transports.
 The discussion around this doc has been very useful for clarifying (to me)
how difficult it can be to pull useful common abstractions out of the 30+
years of transport technologies.  Having been down this path for over a
year, I appreciate the fairly narrow approach draft-welzl-taps-transports
and think it may be the best chance for TAPS to succeed.

Please share your views.

--aaron


On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl  wrote:

> +1
>
> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit 
> wrote:
> >
> > Makes sense.
> >
> >> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk wrote:
> >>
> >> We seem to have two documents in a space where we started with one.
> These
> >> are different, to me this is OK. Both seem close to charter milestone
> 1. I
> >> don't see much overlap between the contents of the descriptive language
> >> and the API-focussed analysis, and any overlap could be eliminated.
> >>
> >> To me, doc 1 (current chartered item) can evolve to provide background
> and
> >> missing documentation for anyone in the IETF, and should compare
> >> transports in a broad way and draw out the idea that they provide
> >> services. This appears to be harder to get right than I for one had
> hoped,
> >> and still has a wide scope. Not a bad thing. I suggest it will provide a
> >> reference to stop us rat-holing when people ask what is "this" and
> explain
> >> how all these transports stack-up against one another (good pun?). We
> can
> >> (I suggest) finish this doc in this way.
> >>
> >> I do like the idea of a second document focussed ONLY on the Transport
> API
> >> (I'd call this 1a). In this we can avoid this"discussion of what are
> >> transports"  and move to  a  more focussed  process in doc 1b,  Most of
> >> that troublesome descriptive  text can go into 1, and ensure we keep
> that
> >> one readable to anyone in the  IETF.
> >>
> >> Could  I suggest the two docs against the first milestone will help us
> >> make  progress towards the next milestone faster. (Assuming we can keep
> >> the two aligned, which seems quite doable). I can see also how the  docs
> >> are useful to different people. I'd like to see both mature and provide
> >> inputs to move forward.
> >>
> >> Gorry
> >>
> >>
> >>> Interesting and inline to getting transport API(s)
> >>>
> >>> Marie-José Montpetit
> >>> ma...@mjmontpetit.com
> >>> mari...@mit.edu
> >>>
>  On Sep 21, 2015, at 04:44, Michael Welzl  wrote:
> 
>  Dear all,
> 
>  In my presentation in Prague, I proposed an approach to identify the
>  services that transport protocols provide. At the end of the ensuing
>  discussion, I said that I (with co-authors) would write a draft that
>  explains the proposal by applying the proposed method to TCP and SCTP.
> 
>  We just submitted this document - see below;  I hope that this will
> lead
>  to some discussion on the list...
> 
>  Cheers,
>  Michael
> 
> 
> > Begin forwarded message:
> >
> > From: 
> > Subject: New Version Notification for
> > draft-welzl-taps-transports-00.txt
> > Date: 21 Sep 2015 10:35:33 CEST
> > To: Michael Welzl , Michael Welzl
> > , Michael Tuexen , Naeem
> > Khademi , Michael Tuexen ,
> > Naeem Khademi 
> > Resent-From: 
> >
> >
> > A new version of I-D, draft-welzl-taps-transports-00.txt
> > has been successfully submitted by Michael Welzl and posted to the
> > IETF repository.
> >
> > Name:draft-welzl-taps-transports
> > Revision:00
> > Title:An Approach to Identify Services Provided by IETF
> > Transport Protocols and Congestion Control Mechanisms
> > Document date:2015-09-21
> > Group:Individual Submission
> > Pages:23
> > URL:
> >
> https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-welzl-taps-transports/
> > Htmlized:
> > https://tools.ietf.org/html/draft-welzl-taps-transports-00
> >
> >
> > Abstract:
> > This document describes a method to identify services in transport
> > protocols and congestion control mechanisms.  It shows the approach
> > using TCP and SCTP (base protocol) as examples.
> >
> >
> >
> >
> > 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

Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt

2015-09-26 Thread Michael Welzl 
+1

> On 26. sep. 2015, at 13.28, Marie-Jose Montpetit  
> wrote:
> 
> Makes sense. 
> 
>> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk wrote:
>> 
>> We seem to have two documents in a space where we started with one. These
>> are different, to me this is OK. Both seem close to charter milestone 1. I
>> don't see much overlap between the contents of the descriptive language
>> and the API-focussed analysis, and any overlap could be eliminated.
>> 
>> To me, doc 1 (current chartered item) can evolve to provide background and
>> missing documentation for anyone in the IETF, and should compare 
>> transports in a broad way and draw out the idea that they provide
>> services. This appears to be harder to get right than I for one had hoped,
>> and still has a wide scope. Not a bad thing. I suggest it will provide a
>> reference to stop us rat-holing when people ask what is "this" and explain
>> how all these transports stack-up against one another (good pun?). We can
>> (I suggest) finish this doc in this way.
>> 
>> I do like the idea of a second document focussed ONLY on the Transport API
>> (I'd call this 1a). In this we can avoid this"discussion of what are
>> transports"  and move to  a  more focussed  process in doc 1b,  Most of
>> that troublesome descriptive  text can go into 1, and ensure we keep that
>> one readable to anyone in the  IETF.
>> 
>> Could  I suggest the two docs against the first milestone will help us
>> make  progress towards the next milestone faster. (Assuming we can keep
>> the two aligned, which seems quite doable). I can see also how the  docs
>> are useful to different people. I'd like to see both mature and provide
>> inputs to move forward.
>> 
>> Gorry
>> 
>> 
>>> Interesting and inline to getting transport API(s)
>>> 
>>> Marie-José Montpetit
>>> ma...@mjmontpetit.com
>>> mari...@mit.edu
>>> 
 On Sep 21, 2015, at 04:44, Michael Welzl  wrote:
 
 Dear all,
 
 In my presentation in Prague, I proposed an approach to identify the
 services that transport protocols provide. At the end of the ensuing
 discussion, I said that I (with co-authors) would write a draft that
 explains the proposal by applying the proposed method to TCP and SCTP.
 
 We just submitted this document - see below;  I hope that this will lead
 to some discussion on the list...
 
 Cheers,
 Michael
 
 
> Begin forwarded message:
> 
> From: 
> Subject: New Version Notification for
> draft-welzl-taps-transports-00.txt
> Date: 21 Sep 2015 10:35:33 CEST
> To: Michael Welzl , Michael Welzl
> , Michael Tuexen , Naeem
> Khademi , Michael Tuexen ,
> Naeem Khademi 
> Resent-From: 
> 
> 
> A new version of I-D, draft-welzl-taps-transports-00.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
> 
> Name:draft-welzl-taps-transports
> Revision:00
> Title:An Approach to Identify Services Provided by IETF
> Transport Protocols and Congestion Control Mechanisms
> Document date:2015-09-21
> Group:Individual Submission
> Pages:23
> URL:
> https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-welzl-taps-transports/
> Htmlized:
> https://tools.ietf.org/html/draft-welzl-taps-transports-00
> 
> 
> Abstract:
> This document describes a method to identify services in transport
> protocols and congestion control mechanisms.  It shows the approach
> using TCP and SCTP (base protocol) as examples.
> 
> 
> 
> 
> 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
 Taps@ietf.org
 https://www.ietf.org/mailman/listinfo/taps
>>> 
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>> 
>> 
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps