Hi, thanks! Below:
> On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > HI, > > A few initial comments the definition of the transport service features as > they appear from section 3 (and TAPS1): > > Unidirectional/bidirectional: I am not sure what this means exactly: > Does it refer to that data transfer is negotiated for both directions > perhaps ? But then it only applies to connection oriented transport. > Does it refer to that control info is going back ? > Does it refer to that messages (which ever form) are going back on the > reverse network path ? Then it does not necessarily apply to SCTP MH. Sorry for not being clear enough: it means that it's a feature that can be used just on one side, without requiring the other side to be involved (e.g. Nagle is just a sender-side mechanism). > o non-reliable delivery: > add SCTP > > o reliable delivery: > add SCTP > > Suggest to rephrase > > o reliable and partially reliable delivery > --> > o partially reliable delivery: > SCTP > > o drop notification : > add SCTP > > o ordered delivery: > add SCTP > > o unordered delivery: > add SCTP ACK, thanks > Ideally, I think, then one would use a common term for Nagle(-like) > bundling for TCP and SCTP. Agreed, we actually did that in Michael Welzl, Stefan Jörer, Stein Gjessing: "Towards a Protocol-Independent Internet Transport API", FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June 2011, Kyoto, Japan, using app PDU bundling because it's more meaningful than Nagle. But here the idea was just to copy+paste the list from doc 1 (version 4) and put things under the correct headings, as a way to show how we *could* apply categorization methods. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
