s unnecessary reliability might be allowed as an
>equivalent Protocol Stack as long as it does not conflict with
>any other application-requested properties.
>
> If you think we can clarify this any further, let me know!
>
> Thanks,
> Tommy
>
>> On Jul 23, 2019, at 11:5
> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt
> wrote:
>
> Another important difference between TCP and UDP are Message Boundaries.
> So in some cases, TCP + Framer may be equivalent to UDP.
FWIW, they might provide *similar* capabilities, even only those that the app
is concerned about, b
FWIW, #8 was raised when MPTCP was created - I pointed out that this
system, like HTTP muxing, was doomed to needing to reinvent the whole of
IP at the TCP layer (or HTTP layer, for HTTP muxing). That includes
differentiated services.
Joe
On 3/21/2018 10:10 AM, Aaron Falk wrote:
>
> Mark Handley
On 6/16/2017 11:23 AM, Tommy Pauly wrote:
> - I’d love to see the terminology be less sockets-specific, especially
> considering the work for Post-Sockets APIs. A set of intents should be able
> to be applied to individual messages being sent or on a higher-level
> protocol, ideally, not just
FWIW:
On 5/12/2017 5:31 AM, Michael Welzl wrote:
>> ---
>> Get Interface MTU is missing from pass 2 and 3:
>>
>> ADD to pass 2:
>>
>> GET_INTERFACE_MTU.UDP:
>> Pass 1 primitive: GET_INTERFACE_MTU
>> Returns: Maximum datagram size (bytes)
> But this d
Hi, Michael,
Sorry for the delay...
On 4/5/2017 11:54 PM, Michael Welzl wrote:
> BTW,
>
> Just a quick last question, to make sure I get this right:
>
> Oh, OK - then you would want to say that the keyID and nextkeyIDs fall
> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section
On 4/5/2017 2:23 PM, Michael Welzl wrote:
>> On Apr 5, 2017, at 10:33 PM, Joe Touch wrote:
>>
>> Hi, Michael,
>>
>>
>> On 4/5/2017 1:10 PM, Michael Welzl wrote:
>>>> On Apr 5, 2017, at 9:55 PM, Joe Touch wrote:
>>>> ...
>>>
Hi, Michael,
On 4/5/2017 1:10 PM, Michael Welzl wrote:
>> On Apr 5, 2017, at 9:55 PM, Joe Touch wrote:
>> ...
>> Set_auth and get_auth are either in the STATUS (as per my previous
>> message) or SEND/RECEIVE.
> What’s the problem with defining new primitives for th
On 4/5/2017 12:46 PM, Michael Welzl wrote:
> There isn’t much; Nagle is an example - RFC 1122 just says that the
> functionality to enable / disable must be there, without specifying via which
> primitive that would happen.
> So, my draft says, in pass 2:
>
>o DISABLE_NAGLE.TCP:
> Pa
On 4/5/2017 12:46 PM, Michael Welzl wrote:
>> On Apr 5, 2017, at 9:31 PM, Joe Touch wrote:
>>
>>
>>
>> On 4/5/2017 12:12 PM, Michael Welzl wrote:
>>> Hi,
>>>
>>> Thanks a lot for checking this!
>>>
>>>
>>>> On Apr 5, 2
On 4/5/2017 12:12 PM, Michael Welzl wrote:
> Hi,
>
> Thanks a lot for checking this!
>
>
>> On Apr 5, 2017, at 8:01 PM, Joe Touch wrote:
>>
>>
>>
>> On 4/5/2017 5:45 AM, Michael Welzl wrote:
>>> This is the minor change that I pro
On 4/5/2017 5:45 AM, Michael Welzl wrote:
> This is the minor change that I promised at the last meeting - mainly to
> include TCP Authentication (RFC 5925).
There are bugs in the description. TCP-AO was careful to say "TCP SEND,
or a sequence of commands resulting in a SEND" (same for RECEIVE),
Hi, all,
Some observations:
- HE-trans MUST NOT be used to try different combinations of options
within a given transport
- I'm wondering about the potential for problems when ports are reused
between different attempts, e.g., IPv6-TCP then IPv4-TCP
- the document works only for connection-orie
t doc claims to try to optimize to the native link MTU,
but that doesn't appear to be possible given the way IPv4 and IPv6
interact with transports. There's no signal to IP that says "don't
source fragment".
Joe
On 12/14/2016 11:12 AM, Joe Touch wrote:
> Hi, Gorry,
&
Hi, Gorry,
Let me see of I can explain my viewpoint.
I'll start by noting that there's a difference between "what transports
currently do" and what they "should" do. I agree with you that current
transports do have access to network MTUs and DF control, but don't
always pass all that to the user.
On 12/13/2016 5:34 AM, Gorry Fairhurst wrote:
> ...
>>>
>>> (1) I think we need a parameter returned to the App that is
>>> equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is
>>> useful to know how many bytes the app can send with reasonable
>>> chance of unfragmented delivery.
All
On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:
>>
>> IMO, the app should never need to play with DF. It needs to know what it
>> thinks the transport can deliver - which might include transport
>> frag/reassembly and network frag/reassembly.
> How does the App handle probes for path MTU then in U
On 12/12/2016 3:45 AM, Gorry Fairhurst wrote:
>>
>> So what does that mean: that the API should contain a "don't
>> fragment" flag from the application?
>>
> Definitely.
>
> The use of DF in a datagram protocol is per-datagram decision -
> depending on what the app needs to happen.
>
> gorry
IMO
On 12/12/2016 1:31 AM, Michael Welzl wrote:
> Hi,
>
> Just trying to understand, so we're not talking past each other. Please note
> that I'm not trying to argue in any direction with my comments below, just
> asking for clarification:
Sure...
>
>> On 09 De
On 12/9/2016 1:38 PM, Michael Tuexen wrote:
>> On 9 Dec 2016, at 22:30, Joe Touch wrote:
>>
>>
>>
>> On 12/9/2016 1:26 PM, Michael Tuexen wrote:
>>> Not sure what the reassembly limit is... SCTP handled arbitrary sized
>>> user messages a the rece
On 12/9/2016 1:26 PM, Michael Tuexen wrote:
>
> Not sure what the reassembly limit is... SCTP handled arbitrary sized
> user messages a the receiver side by using partial delivery.
>
> The SCTP_MAXSEG allows a user to limit the size of DATA chunks without
> reducing the pmtu.
Yes, but that size c
On 12/9/2016 12:28 PM, Michael Tuexen wrote:
>> ...
>>> In the API description in https://tools.ietf.org/html/rfc6458 the MTU
>>> exposed to the application
>>> via the API is "the number of bytes available in an SCTP packet for
>>> chunks." I think this is the best
>>> we can do at that interf
On 12/9/2016 12:14 PM, Michael Tuexen wrote:
>> On 7 Dec 2016, at 15:54, Michael Welzl wrote:
>>
>> Hi all,
>>
>> I have a problem with one particular primitive, or lack of it, in UDP,
>> UDP-Lite and SCTP. It's something I just don't get.
>>
>> Consider this text from draft-fairhurst-taps-tran
On 12/9/2016 12:56 AM, Michael Welzl wrote:
> These things can be achieved by only changing the implementation of
> transports to locally provide some more of its internal information to a
> system on top; they don't change anything on the wire...
FWIW, we really need to stop using that phrase
On 12/9/2016 8:12 AM, Michael Welzl wrote:
>> On 09 Dec 2016, at 16:18, Joe Touch wrote:
>>
>>
>>
>> On 12/9/2016 12:09 AM, Michael Welzl wrote:
>>>> On 07 Dec 2016, at 20:29, Joe Touch wrote:
>>>>
>>>> FYI, there are two dif
On 12/9/2016 12:09 AM, Michael Welzl wrote:
>> On 07 Dec 2016, at 20:29, Joe Touch wrote:
>>
>> FYI, there are two different "largest messages" at the transport layer:
>>
>> 1) the size of the message that CAN be delivered at all
> True... I wasn'
FYI, there are two different "largest messages" at the transport layer:
1) the size of the message that CAN be delivered at all
2) the size of the message that can be delivered without network-layer
fragmentation (there are no guarantees about link-layer - see ATM or the
recent discussion on tunn
Hi, Gorry (et al.),
On 10/10/2016 9:56 AM, go...@erg.abdn.ac.uk wrote:
> ...
> OK, so in the context of TAPS, the WG called for a list of UDP services.
> This is what is in the ID. ...
>
> This ID clearly isn't an API spec.
>
> ...
> I don't personally know whether an API spec for UDP is useful
On 10/10/2016 3:15 AM, Gorry (erg) wrote:
> ... There is no document in the RFC series that document UDP API - this may
> be helpful roadmap to find this info. Two documents are easier to maintain
> and cite than one.
RFC1122 defines one in Section 4.1.4, but it basically points off to a
defin
On 7/19/2016 9:05 AM, Mirja Kühlewind wrote:
> Hi,
>
> for multicast there is the simple example where one access network is more
> expensive to use than the other (in the sense where the user gets a bill at
> the end). In this case the user would potentially rather except a disconnect
> for a
On 7/19/2016 8:49 AM, Michael Welzl wrote:
>> On 19. jul. 2016, at 17.40, Joe Touch wrote:
>>
>>
>>
>> On 7/19/2016 5:27 AM, Michael Welzl wrote:
>>> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS
>>> is the day a
On 7/19/2016 5:27 AM, Michael Welzl wrote:
> Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS
> is the day after, which fits nicely.
>
> Note, I phrased this controversial on purpose to generate a bit of list
> discussion: “abstracting away” something like usage of mu
On 6/6/2016 11:20 AM, Michael Welzl wrote:
>> On 6. jun. 2016, at 19.15, Joe Touch wrote:
>>
>>
>>
>> On 6/6/2016 1:17 AM, Michael Welzl wrote:
>>>> On 27 Apr 2016, at 23:25, Joe Touch wrote:
>>>>
>>>>
>>>>
>>
On 6/6/2016 1:17 AM, Michael Welzl wrote:
>> On 27 Apr 2016, at 23:25, Joe Touch wrote:
>>
>>
>>
>> On 4/27/2016 1:16 AM, Michael Welzl wrote:
>>> Thinking about Toerless' general point of using more modern APIs made
>>> me think of t
On 4/27/2016 1:16 AM, Michael Welzl wrote:
> Thinking about Toerless' general point of using more modern APIs made
> me think of the bigger picture again. For example, one cool recent
> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows
> better control of the sender buffer. Not i
On 4/7/2016 11:42 AM, Dale R. Worley wrote:
> go...@erg.abdn.ac.uk writes:
>> I agree - the current format from the text comes from the existing text
>> for TCP and SCTP in another draft. and I think we may need to work out
>> how to handle
>> [...]
>> I probably need help - I think there are d
On 4/7/2016 11:44 AM, Dale R. Worley wrote:
> Joe Touch writes:
>> For connectionless protocols, "CONNECT" is often the basic primitive by
>> which a user indicates the socket pair (address/port) of the remote end.
>
> The trouble I see is that the concept of
On 4/6/2016 9:39 AM, go...@erg.abdn.ac.uk wrote:
...
>> I'm reading parts of draft-fairhurst-taps-transports-usage-udp-01
>> because it was presented in the Dispatch session of the meeting, so I
>> don't have all the context for this draft. But a couple of comments
>> struck me:
>>
>> The descri
On 4/4/2016 3:31 PM, go...@erg.abdn.ac.uk wrote:
>> My point is that - at the abstract level - UDP should not have an API
>> > that talks about DSCP, ECN, or TTL - that ought to be something opaque
>> > that UDP hands down underneath.
>> >
> And does this particular list of things vary between IP
On 4/4/2016 12:49 PM, go...@erg.abdn.ac.uk wrote:
...
>>> No. It's true that UDP needs to know this, but this info needs to arrive
>>> at the App, either from a primitive that returns the size or from a
>>> failed
>>> send call when probing for a maximum datagram size. The app also may
>>> need
>
On 4/4/2016 11:24 AM, go...@erg.abdn.ac.uk wrote:
> Hi Joe,
>
> We don't seem to be agreeing.
Not yet at least ;-)
...
>> For MSS and segment size, the same ought to be true for UDP.
>>
> No. It's true that UDP needs to know this, but this info needs to arrive
> at the App, either from a primi
Hi, Gorry,
On 4/4/2016 10:55 AM, go...@erg.abdn.ac.uk wrote:
> I was thinking in terms of what we were trying to achieve within TAPS, and
> from that perspective things like: ECN-marks, Maximum datagram/segment
> size, etc. I do not think through the TCP API (for instance), since these
> concern t
On 4/3/2016 4:54 AM, go...@erg.abdn.ac.uk wrote:
> When someone talks about using TCP or SCTP then they are typically using
> an API to the transport that hides a lot of details.
I'm not sure I agree with this.
IMO, TCP defines an API that is intended to provide a service capability
that it ren
On 4/4/2016 10:31 AM, Joe Touch wrote:
> AFAIR, this is the difference between unix close() and shutdown(). The
> former disconnects both the connection and the OS endpoint, whereas the
> latter "undoes" the corresponding connect() but not the socket creation,
> allowing ha
On 4/3/2016 5:20 PM, Toerless Eckert wrote:
> Eg: Consider someone used the transport service definitions of this drat
> randomnly,
> there is no way to figure out which would or would not succeed, because
> there is
> no definition how send/received packets are associated to transp
On 1/30/2016 11:59 PM, Michael Welzl wrote:
...
> The main question on the table is: provided that we'll incorporate
> such comments, should this be a product of the WG?
It's not clear it's a separate doc. It might be more useful as part of
the use case description of other docs, but there's no
This might be a useful document, but it seems like it overlooks a few
"elephants in the room":
1) lots of services use TCP or UDP because they want to work through NATs
2) lots of services do just fine with the services provided by TCP or UDP
It would be useful to address those issues head-on. O
On 11/3/2015 5:27 PM, Karen Elisabeth Egede Nielsen wrote:
> HI,
>
> As a general comment then I believe that when describing what is supported
> by TCP/SCTP (or UDP) as standard then it does not suffice to look into
> IETF RFCs.
> One need at least to relate to the *basic functions* of the POSI
l.
RFC1122 is a standards track doc that clearly updates RFC793, even
though that sort of marking was not part of IETF process when it was issued.
Joe
>
> BR, Karen
>
>> -Original Message-
>> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Joe Touch
>> Sen
On 11/3/2015 5:33 AM, go...@erg.abdn.ac.uk wrote:
> GF: From a TSVWG Chair perspective, beware here... *ALL* more recent IETF
> SCTP API work from TSVWG is INFO. Each SCTP RFC is expected to have an
> informative section that describes the API together with the normative
> protocol spec. That i
+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
Hi, Kasren,
[Michael]:
>>> For SCTP we allow for that Nagle is disabled on some streams (streams
>>> with high scheduling priority) and not on others. This is done exactly
>>> for this purpose.
[Joe]:
>> Sure, but that's also why it doesn't make sense for TCP.
> [Karen ] Yes and then also why Na
Hi, Karen,
On 7/16/2015 12:57 AM, Karen Elisabeth Egede Nielsen wrote:
>> What portion of RFC793's API do you consider outdated?
> HI,
>
> I was thinking about the PUSH flag mainly.
>
> In our socket api implementation we do not allow for set of PUSH in send
> calls nor do we provide the PU
On 7/16/2015 1:56 AM, Michael Tuexen wrote:
>> > So, IMO, this is a great example of why studying these APIs as
>> > abstractions is important and would have prevented this (IMO) oversight.
>
> Can you say specifically, what has been missed?
>
> My understanding is that SCTP and TCP are similar
On 7/16/2015 3:26 AM, Karen Elisabeth Egede Nielsen wrote:
> I think that one could say that RFC4960 Appendix C prescriptions for how
> to handle soft icmps could relate to that this can make the assocs enter
> dormant state fast and that dormant state implementation
> need to relate to this fac
On 7/16/2015 2:40 AM, Michael Tuexen wrote:
>> [Karen ] We provide information about received destination unreachable
>> > ICMPs to users via socket api.
>> > The same we do for (connected) UDP.
>> >
>> > This we could also do for SCTP, but as said we don't do it (yet).
>
> OK. FreeBSD does this
On 7/16/2015 12:01 AM, Karen Elisabeth Egede Nielsen wrote:
> HI Joe,
>
> I generally agree with your comments, but the situations is not
> necessarily as bad as you say.
> Please see below.
...
>> Agreed, however the other ways that SCTP doesn't pass validated ICMPs to
>> the user seems like a
Hi, Karen,
On 7/16/2015 12:27 AM, Karen Elisabeth Egede Nielsen wrote:
...
>> So there are several levels of the latency issue:
>>
>> - minimize the latency ADDED by the transport layer
>> - reduce the latency seen by the app
>> (which can involve more active interaction with the ne
On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote:
...
Any pitfalls with ICMP when doing SCTP?
>>>
>>> In many ways, SCTP subsumes similar requirements as TCP, but that's
>>> probably buried in the SCTP docs.
>> It is. See
>> https://tools.ietf.org/html/rfc4960#appendix-C
>>
>
> [Ka
On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote:
> HI Mirja, All
>
> Sorry for jumping late into this discussion.
...
> I really do not think that it makes much sense to look into outdated and
> deprecated APIs
> as specified in RFC793 and RFC4960 when we have better material available
On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen wrote:
> Hi,
>
> Please find a very few comments to the document. Nothing major. Please use
> if you see fit and only then :-)
>
> Section 1: End First Paragraph:
>
> Here it is said that a transport service feature may be minimal latency.
>
Michael,
On 6/20/2015 1:35 AM, Michael Welzl wrote:
On 20. jun. 2015, at 00.55, Joe Touch wrote:
On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
...
Let's put it this way:
- if the goal of TAPS is to unify existing APIs,
then those APIs need to be summarized together i
On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch mailto:to...@isi.edu>> wrote:
You're getting far ahead of the conversation, IMO. This document
needs to start by explaining the services we already have before
jumping into a
On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote:
Of course, no one use a protocol without knowing the service it offers.
When the application requests a TCP connection, it really request a
reliable and ordered connection oriented service. The protocols
primitives are used to each one to offer a p
On 6/19/2015 6:22 AM, Michael Welzl wrote:
>
> On 19 Jun 2015, at 14:03, Mirja Kühlewind
> wrote:
>> So there current API is always bound to a specify protocol which
>> already provides you a certain set of service feature. At least in
>> TCP there is not much choice left and there the current
On 6/19/2015 7:15 AM, Mirja Kühlewind wrote:
> Cool! I think that the alternative approach Brian just proposed:
> Start with the feature we think/know we want to have and the compare
> them with what we have in the first document.
-1
If you don't know what you already have, it's hard to figure
+1
On 6/18/2015 9:44 AM, Michael Welzl wrote:
*My* goal is, and has always been, to provide a simpler, general API
that is protocol independent. Note that this is not only for
simplicity for ease of use BUT also for the sake of being able to
automatize. After all the major goal is to remove the
On 6/17/2015 1:44 AM, Michael Welzl wrote:
> I think that this discussion with Joe maybe suffered from focusing on
> TCP.
To be fair, TCP has a simpler abstract API.
> SCTP is perhaps a better starting point because it supports
> almost everything.
IMO, that makes it very hard as a starting
On 6/11/2015 5:30 AM, go...@erg.abdn.ac.uk wrote:
...
>> - Port multiplexing, with application-to-port mapping during connection
>> setup:
>
> GF: Thinking on this, is application-to-port mapping really a TCP
> function? port-mapping is similar in other transports, and doesn't really
> have any
covers the case where HTTP over TCP is used as a
> transport ‚substitute‘.
HTTP isn't a transport protocol. I don't know anyone who would call it
that or be able to use it as a substitute for TCP.
Joe
> Mirja
>
>
>
>> Am 04.06.2015 um 23:20 schrieb Joe Touch :
&
On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
>
>
> On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch <mailto:to...@isi.edu>> wrote:
>
>
>
> On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> > I think that speaking specifically about any protocol in this
On 6/5/2015 5:11 AM, Helge Backhaus wrote:
> Am 04.06.2015 um 23:20 schrieb Joe Touch:
...
>> There are many services built on top of HTTP, at which point HTTP is just
>> another part of what this document calls a "transport service".
>>
>> As a result, unles
On 6/5/2015 4:29 AM, Mirja Kühlewind wrote:
> I do have the feeling that parts of what Joe wants to discuss should
> however be in the third doc. And therefore I think that the current
> first doc is not the taps flagship doc because for me a flagship doc
> (and we probably need to define this te
On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote:
>
>> On 04 Jun 2015, at 22:56, Joe Touch > <mailto:to...@isi.edu>> wrote:
>>
>>
>>
>> On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
>>>
>>>> On
On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote:
> In my presentation in Dallas I had suggested adding RTP (and even
> HTTP) because as both Mirja and Christian mention some 'applications'
> are requesting functionalities that are got given elsewhere.
The core of this issue is "what is a transp
On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> I think that speaking specifically about any protocol in this document
> will not be in the sens of an "abstract" interface for the Transport
> layer, because abstraction means that application will no longer be
> aware of who or what Transport servi
On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
>
>> On 04 Jun 2015, at 21:17, Joe Touch wrote:
>>
>>
>>
>> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
>> ...
>>>> UDP passes all ICMP messages to the app. If the app do
On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
...
>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>> it, that’s the app's decision.
>>
> Then there is a lot UDP application developers out there that does not care.
>
> Ill guess what I am asking if we should mak
On 6/4/2015 3:34 AM, Mirja Kühlewind wrote:
> It's in the doc:
>
> "Application: an entity that uses the transport layer for end-to-end
> delivery data across the network (this may also be an upper layer
> protocol or tunnel encapsulation)."
"End to end" is *defined* as the endpoin
On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
>
>> On 04 Jun 2015, at 17:43, Joe Touch > <mailto:to...@isi.edu>> wrote:
>>
>>
>>
>> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote:
>> ...
>>> Does it make sense for the TAPS
On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote:
...
> Does it make sense for the TAPS transports draft to add ICMP?
ICMP is not a transport protocol.
The ways in which transport protocols either terminate or pass-through
ICMP messages is part of the transport protocol abstract API.
E.g.,
On 6/1/2015 1:34 PM, Michael Welzl wrote:
>> Segmentation is HOW TCP gives you a reliable byte-sequence service over
>> a packet service.
>>
>> It is absolutely NOT something provided to the user or under user
>> control. Users can set MTU values on *some systems*, but that's not part
>> of
On 6/1/2015 12:23 PM, Michael Welzl wrote:
> I'll try addressing another detail, maybe that helps get us aligned:
>
>
>> On 1. jun. 2015, at 21.38, Mirja Kühlewind
>> wrote:
>>
>> Hi Joe
>>>
>>> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
>>
>> Yes, that’s actually
On 6/1/2015 11:38 AM, Mirja Kühlewind wrote:
> Hi Joe
>>
>> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
>
> Yes, that’s actually true. Initially there was no section 3.1.2 as
> this doc is not on interfaces. However it seems to be incomplete without
> mentioning interf
On 6/1/2015 9:45 AM, Michael Welzl wrote:
>
>> On 1. jun. 2015, at 16.32, Mirja Kühlewind
>> wrote:
>>
>> Hi Joe, hi Michael,
>>
>> I completely welcome to add more text to the Interface description section
>> (3.1.2). Currently this section is very short and says regarding the (higher
>> la
First, I think this discussion would benefit from a clarification of
what "API" means, or at least to stop using that term in isolation.
There are three distinct concepts:
A- abstract protocol "upper layer interface"
e.g., OPEN, CLOSE, ABORT, as per RFC 793
B-
On 5/28/2015 11:05 AM, Mirja Kühlewind wrote:
> Hi Joe,
>
> here is where the confusion comes from: this doc is not about APIs,
> it’s about transport services, or to say it even more concrete,
> transport services components and features.
Such services are either inherent to the transport (e.g
On 5/28/2015 1:49 AM, Mirja Kühlewind wrote:
> Hi Joe,
>
> see below...
>
>
>> Am 27.05.2015 um 19:20 schrieb Joe Touch :
>>
>>
>> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
>>> Hi Joe,
>>>
>>> I agree. This is a working d
e augmented with options and later extensions), but that needs to be a
*starting point* for these discussions.
And the current doc doesn't come close to what's in 793.
If we're not starting there, there's little point in starting IMO.
Joe
> Mirja
>
>
>> Am 27
Hi, Brian (et al.),
On 5/26/2015 6:25 AM, Brian Trammell wrote:
...
> (3) frontmatter in Section 4 normalizing and categorizing the
> transport protocol components; please review this and suggest necessary
> or useful changes for using this as background for selecting taps features.
I like the de
On 3/23/2015 11:06 AM, Michael Welzl wrote:
>
>> On 23. mar. 2015, at 11.34, Joe Touch wrote:
>>
>>
>>
>> On 3/22/2015 7:34 AM, Michael Welzl wrote:
>>> Major:
>>> - I do think that the terminology actually needs to clarify about
>>&
On 3/22/2015 7:34 AM, Michael Welzl wrote:
> Major:
> - I do think that the terminology actually needs to clarify about
> what a "service" is. Following the chain of dependencies here, it is found in
> "Transport Service", where it says "... which provides a complete
> service to an application."
On 3/4/2015 6:10 PM, Simone Ferlin-Oliveira wrote:
> 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”, abstractin
On 2/4/2015 2:55 PM, Marie-Jose Montpetit wrote:
Well one reason I started being interested in TAPS was because of the
video and of course the multisource version (video for example combining
streaming, download, multimedia and social networking). For these use
cases you need to be able to spec
Hi, Mirja,
On 2/4/2015 8:59 AM, Mirja Kühlewind wrote:
> Hi Joe.
>
> see below...
>
> On 30.01.2015 20:23, Joe Touch wrote:
>> Hi, Mirja,
>>
>> On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
>>> Hi Joe,
>>>
>>> I reply to the TCP part
On 2/2/2015 12:48 PM, Michael Welzl wrote:
So, in summary, yes, an API from transport to the service layer
should have an indication of latency, but this is a very
complex,*bidirectional* interface. So other than saying that this
should be addressed in the future, anything said now will be at
On 1/30/2015 7:20 AM, Wolfgang Beck wrote:
Would it make sense to include statements about latency?
Yes, but I'm not sure what at this point.
Latency is a multidimensional property; it depends on the interaction of
a variety of factors, so even if you wanted to have the application say
"I
Hi, Mirja,
On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
Hi Joe,
I reply to the TCP part in this mail... see below.
On 19.12.2014 00:39, Joe Touch wrote:
Some feedback below. Although I focus on some TCP and UDP specifics,
some observations apply to other transports as well.
Joe
gt; Gorry
>
>> One additional point:
>>
>> TCP services described in 3.1.3 should also include PUSH and URG
>> capabilities.
>>
>> FWIW, the specific section of RFC793 that defines the TCP interfaces -
>> above and below - is 3.8.
>>
>> Joe
&g
On 12/19/2014 2:24 PM, Brian Trammell wrote:
...
> I was trying to make a much less subtle point from the interface side:
> since SCTP actually _has_ a concept of application PDU, it can bundle
> them, while TCP has no such concept, so what it's bundling can't really
> be PDUs.
TCP has three not
1 - 100 of 104 matches
Mail list logo
