Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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 in this mail... see below. >>> >>> On 19.12.2014 00:39, Joe Tou

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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 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 obse

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 2. feb. 2015, at 19.03, Joe Touch wrote: > > > > 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

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 1. feb. 2015, at 08.51, go...@erg.abdn.ac.uk wrote: > >> Would it make sense to include statements about latency? >> > I think if we come to think about the API that could be presented by TAPS > to the application, we'll need to focus on what characteristics the Apps > expect from the netwo

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> Would it make sense to include statements about latency? > I think if we come to think about the API that could be presented by TAPS to the application, we'll need to focus on what characteristics the Apps expect from the network. Low latency is clearly one service that many apps will desire. >

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

Would it make sense to include statements about latency? We recently had a discussion with one of our suppliers about application layer timeouts that fired while the request was still stuck in the send queue. There were statements like 'UDP never queues' or 'we can't control the TCP send buffer s

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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 - 3.1.1

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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 - 3.1.1 TCP segments fit into IP packets, but those packe

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

Hi, Gorry, On 12/22/2014 8:53 AM, go...@erg.abdn.ac.uk wrote: > I can see the merits of discussing PUSH, but if this advice is for usage > in the future, I think RFC 6093 says SHOULD NOT use, due to the range of > TCP implementations that process TCP urgent indications differently. That > makes m

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

I can see the merits of discussing PUSH, but if this advice is for usage in the future, I think RFC 6093 says SHOULD NOT use, due to the range of TCP implementations that process TCP urgent indications differently. That makes me think it may be wise to note this perhaps, rather than just include i

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

On 20 Dec 2014, at 00:14, Michael Welzl wrote: > >> On 20. des. 2014, at 09.24, Michael Tuexen wrote: >> >> On 19 Dec 2014, at 23:08, Michael Welzl wrote: >> >>> On 20. des. 2014, at 01.13, Brian Trammell wrote: hi Michael, > On 19 Dec 2014, at 10:29, Michael Welz

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 20. des. 2014, at 09.24, Michael Tuexen wrote: > > On 19 Dec 2014, at 23:08, Michael Welzl > wrote: > >> >>> On 20. des. 2014, at 01.13, Brian Trammell wrote: >>> >>> hi Michael, >>> On 19 Dec 2014, at 10:29, Michael Welzl wrote: > On 1

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

On 19 Dec 2014, at 23:08, Michael Welzl wrote: >> >> On 20. des. 2014, at 01.13, Brian Trammell wrote: >> >> hi Michael, >> >>> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >>> >>> On 19. des. 2014, at 20.05, Brian Trammell wrote: > On 18 Dec 2014, at 22:37, Michae

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

On 19 Dec 2014, at 23:08, Michael Welzl wrote: > >> On 20. des. 2014, at 01.13, Brian Trammell wrote: >> >> hi Michael, >> >>> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >>> >>> On 19. des. 2014, at 20.05, Brian Trammell wrote: > On 18 Dec 2014, at 22:37, Michael

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 20. des. 2014, at 01.13, Brian Trammell wrote: > > hi Michael, > >> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >> >> >>> On 19. des. 2014, at 20.05, Brian Trammell wrote: >>> >>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: Hi, Thanks for this update

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

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 On 12/18/2014 3:39 PM, Joe Touch wrote: > Some feedback below. Although I focus on some TCP a

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 19 Dec 2014, at 10:35, Michael Welzl wrote: > >> >> On 19. des. 2014, at 20.29, Michael Welzl wrote: >> >> >>> On 19. des. 2014, at 20.05, Brian Trammell wrote: >>> >>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: Hi, Thanks for this update! A

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

hi Michael, > On 19 Dec 2014, at 10:29, Michael Welzl wrote: > > >> On 19. des. 2014, at 20.05, Brian Trammell wrote: >> >> >>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>> >>> Hi, >>> >>> Thanks for this update! >>> >>> A question: >>> We've posted a -01 rev of the TAPS tran

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 19. des. 2014, at 20.29, Michael Welzl wrote: > > >> On 19. des. 2014, at 20.05, Brian Trammell wrote: >> >> >>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>> >>> Hi, >>> >>> Thanks for this update! >>> >>> A question: >>> We've posted a -01 rev of the TAPS transports doc

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 19. des. 2014, at 20.05, Brian Trammell wrote: > > >> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >> >> Hi, >> >> Thanks for this update! >> >> A question: >> >>> We've posted a -01 rev of the TAPS transports document. We believe that the >>> format and level of detail for the TCP

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

> On 18 Dec 2014, at 22:37, Michael Welzl wrote: > > Hi, > > Thanks for this update! > > A question: > >> We've posted a -01 rev of the TAPS transports document. We believe that the >> format and level of detail for the TCP section is about what we're targeting >> for each of the other sect

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt (UDP)

Thanks Joe, This is very much a first attempt to quickly put a little substance on the framework, to see if it can work and gather thoughts. Your read through is helpful I'll reply just to the UDP feedback below: > Some feedback below. Although I focus on some TCP and UDP specifics, > some obser

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

Some feedback below. Although I focus on some TCP and UDP specifics, some observations apply to other transports as well. Joe - 3.1.1 TCP segments fit into IP packets, but those packets are not necessarily constrained to fit into a lower-layer frame. They can be sourc

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

Hi, Thanks for this update! A question: > We've posted a -01 rev of the TAPS transports document. We believe that the > format and level of detail for the TCP section is about what we're targeting > for each of the other sections, but this is still open to discussion. Why is Nagle not a part

Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt

Greetings, all, We've posted a -01 rev of the TAPS transports document. We believe that the format and level of detail for the TCP section is about what we're targeting for each of the other sections, but this is still open to discussion. The document also includes at least a little text on mos

[Taps] I-D Action: draft-ietf-taps-transports-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services Working Group of the IETF. Title : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godr