Re: [Taps] TAPS Dinner/Lunch at IETF117

[Colin Perkins]

On 13 Jul 2023, at 9:50, Philipp S. Tiesel wrote:

>> On 12. Jul 2023, at 21:08, Gorry Fairhurst  wrote:
>>
>> On 12/07/2023 19:41, Reese Enghardt wrote:
>>>
>>> On 7/12/23 11:10, Tommy Pauly wrote:
 I’d be happy to meet up with TAPS folks for Monday/Tuesday/Wednesday lunch 
 slots, depending on availability of everyone!
>>>
>>> That would work for me, too.
>>>
>>> Best,
>>> Reese
>>
>> For me: Monday seem best, then Tuesday, then Wednesday.
>>
>> Gorry
>
> All three options would work for me … lets’ wait for Monday an fix Monday 
> Lunch if there is no veto.

Monday is RSAB and Wednesday is the WG Chair Forum, so I'd prefer Tuesday.

Colin

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

Re: [Taps] Conflict with next meeting - Jan 26

[Colin Perkins]

I’ll definitely miss the first hour; unclear about the second.
Colin



> On 15 Jan 2022, at 21:26, Aaron Falk  wrote:
> 
> Can folks who are planning to attend the TAPS interim on Jan 26 at 11am EST 
> reply to this message?  Let’s see if we still have a critical mass.
> 
> —aaron
> 
> On Fri, Jan 14, 2022 at 5:26 AM Mirja Kuehlewind 
>  > wrote:
> Hi all,
> 
> I just notice that I have a conflict with the next meeting. In the first half 
> we now scheduled an IESG/IAB workshop, which will also impact Tommy and 
> Colin. And the second half collides with the joint ADD/DPRIVE/DNSOP interim 
> meeting, which I guess also impacts Tommy and maybe others.
> 
> You definitely don't have to move the meeting because of me but maybe it 
> would be good to check again who would be actually able to join.
> 
> Mirja
> 
> 
> 
> ___
> 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

Re: [Taps] UDP rendezvous

[Colin Perkins]

> On 27 Apr 2020, at 12:38, Michael Welzl  wrote:
> 
> Hi,
> 
> I’m answering this email, but Magnus, consider yourself answered too with a 
> big THANK YOU for your thorough explanation!
> 
> I agree that we want some (much!) of this functionality “under the hood” if 
> possible. And, of course, I agree that we don’t want the application to be 
> aware of e.g. UDP specifically if we can avoid it. I think we’re all on the 
> same page on that; but I think that, indeed, the text in the API draft needs 
> some fixing.
> 
> Colin, thank you very much for outlining the 5 steps below: they give a very 
> good context for this conversation. So, I answer in line below:
> 
>> On Apr 27, 2020, at 12:23 PM, Colin Perkins  wrote:
>> 
>> Hi,
>> 
>> This is one of the areas where the drafts likely need expanding, but I think 
>> the model is:
>> 
>> 1) application configures STUN (and maybe also TURN) local endpoints
>> 
>> 2) application calls Resolve() on these, to find server reflexive candidates
> 
> These two steps are reflected in the API as it stands, and so this is already 
> reasonably clear, I think. IMO, nothing to do here.
> 
> 
>> 3) application shares these candidates with its peer, via out-of-band means, 
>> and receives remote endpoint candidates from the peer
> 
> Based on Magnus’ email, I suppose that this *could* be done in standard ways 
> with trickle, and hence theoretically put “under the hood” too.
> But, I think that keeping this in the application space for the sake of TAPS 
> is quite reasonable. This step is perhaps implicit in the text, but I think 
> it’s pretty obvious that it would need to happen. People doing rendezvous 
> will have to be aware of this step anyway, so I see no real problem here.

This has to be done by the applications, since it will involve the signalling 
protocol (SIP, WebRTC, etc).

>> 4) application adds remote endpoints for the peer’s candidates
> 
> My first hiccup: I don’t see that this is supported in our current API - how 
> would one add remote endpoints? I think, the way we have it, there’s only one 
> for each Connection.
> Have I overlooked something?

They go on the Preconnection. The allow multiple remotes there.

>> 5) application calls Rendezvous(), which performs the ICE-style probing to 
>> find a working path, based on the candidates, then returns s Connection
> 
> THIS would be really good, but it’s not at all how I read the current text. 
> It says:
> 
> "The Rendezvous() Action causes the Preconnection to listen on the Local 
> Endpoint for an incoming Connection from the Remote Endpoint, while 
> simultaneously trying to establish a Connection from the Local Endpoint to 
> the Remote Endpoint. This corresponds to a TCP simultaneous open, for 
> example.”
> 
> My interpretation of this sentence is that Rendezvous doesn’t do much more 
> than listen + send something, using the same local ports. For TCP, I would 
> have implemented this functionality by just doing an active connect, using a 
> pre-configured local port (TCP will retry sending SYNs, and if both sides 
> issue this call with the correct ports, I guess it all works out eventually). 
> However, from below, it seems to me that such an implementation would be 
> doing way too little!

It sends the STUN packets to probe connectivity. I read this as “establish a 
Connection”, but we maybe need to clarify the wording (or just give an 
additional example).

>> This relies on the Endpoint abstraction supporting STUN, which is maybe 
>> implicit in the drafts. 
> 
> Yes - there is text there about STUN configuration, but nothing about it in 
> the Rendezvous text (unless I missed it, apologies if I have!). And it’s not 
> just STUN, it’s the ICE-style probing, with various candidates supplied, 
> that’s missing.
> 
> 
>> Also, as usual with TAPS, the application doesn’t say that it wants UDP. It 
>> says it wants, e.g., RTP preferably over an unreliable connection, and this 
>> higher-level protocool gives the de-framer the ability to distinguish the 
>> STUN packets from the data packets.
> 
> Okay, I understand this… but what happens if UDP *is* the protocol that is 
> available (not e.g. RTP), and the application calls Rendezvous?
> (I guess failing, with a useful error code, is the best choice, then?)

Applications don’t use raw UDP or TCP – they always run some protocol, however 
trivial inside it, so there’s a framer.

> Again, just to be clear, I agree with everything you say here, and I thank 
> you (and Magnus) again for explaining it to me!   - I just want to get the 
> text right. Actually, I was just trying to understand how to implement this 
> call’s functionality, and was left puzzled.
> 
> Cheers,
> Michael

Cheers,
Colin



-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] UDP rendezvous

[Colin Perkins]

Hi,

This is one of the areas where the drafts likely need expanding, but I think 
the model is:

1) application configures STUN (and maybe also TURN) local endpoints

2) application calls Resolve() on these, to find server reflexive candidates

3) application shares these candidates with its peer, via out-of-band means, 
and receives remote endpoint candidates from the peer

4) application adds remote endpoints for the peer’s candidates

5) application calls Rendezvous(), which performs the ICE-style probing to find 
a working path, based on the candidates, then returns s Connection

This relies on the Endpoint abstraction supporting STUN, which is maybe 
implicit in the drafts. 

Also, as usual with TAPS, the application doesn’t say that it wants UDP. It 
says it wants, e.g., RTP preferably over an unreliable connection, and this 
higher-level protocool gives the de-framer the ability to distinguish the STUN 
packets from the data packets.

Colin




> On 25 Apr 2020, at 13:44, Michael Welzl  wrote:
> 
> I know way too little about rendezvous mechanisms, so I may get this 
> completely wrong - please bear with me!
> It may be that I describe an issue that’s a non-issue. But, if I do 
> understand this right, maybe that’s something which needs fixing?
> 
> Ok, here it goes…
> 
> Our current Rendezvous text in the API draft says the following:
> "The Rendezvous() Action causes the Preconnection to listen on the Local 
> Endpoint for an incoming Connection from the Remote Endpoint, while 
> simultaneously trying to establish a Connection from the Local Endpoint to 
> the Remote Endpoint. This corresponds to a TCP simultaneous open, for 
> example.”
> 
> Now, if an application chooses unreliable data transmission, it may get SCTP 
> with partial reliability, or it may (in the future) get QUIC with datagrams, 
> or whatever…  and then, the protocol may be able to do what’s needed 
> (something similar to a simultaneous open).
> 
> However, in case of UDP:
> - Listening is quite okay,
> - “simultaneously trying to establish a Connection” really means nothing - no 
> packet will be sent.
> 
> I believe that applications doing this over UDP will implement their own 
> “SYN”-type signal for this - but then it’s up to the application, which, over 
> TAPS, would need to:
> - create a passive connection,
> - send a Message from that same connection, i.e. using the same local address 
> and port (I believe?) - which is a matter of configuring the local endpoint, 
> and doable if the underlying transport system can pull it off. I think 
> there’s nothing in our API preventing an application from doing this.
> 
> If all of the above is correct, the problem that I see is that an application 
> may ask for unreliable transmission, and then have one case in which calling 
> “Rendezvous” is the right thing to do, and another case in which it is not - 
> so it would need to be able to distinguish between these two cases: is it a 
> protocol with Rendezvous-capability, or do I have to do it myself.  Maybe, in 
> case of UDP, the call to Rendezvous should just fail, and our text should say 
> that Rendezvous failing would inform the application that it would have to 
> implement it by itself, by issuing Listen and then sending a Message to the 
> peer.
> 
> Thoughts? Am I completely off track, or is this something that needs a text 
> fix?
> 
> Cheers,
> Michael
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps



-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room)

[Colin Perkins]

Okay – in which case, my apologies but I have another meeting and won’t make it.

For Vancouver, it’d be useful if we could schedule the side meeting much 
earlier… 

Colin



> On 21 Nov 2019, at 10:25, Brian Trammell (IETF)  wrote:
> 
> Yes, moving to lunch today; for those who cannot make lunch today, the IAB 
> room is still reserved for tomorrow. Tomorrow is backup for additional time, 
> though a few of us won't be able to make it.
> 
> As with anything planned poorly and the last minute (sorry!) we're not going 
> to converge on getting everyone in the room, and that's OK. Let us take 
> "schedule enough side meeting time in Vancouver *in advance*" as a goal for 
> next time. 
> 
> Cheers,
> 
> Brian
> 
>> On 21 Nov 2019, at 10:22, Colin Perkins  wrote:
>> 
>> Sorry, I’m confused – is this moving to lunch today, rather than tomorrow 
>> morning?
>> Colin
>> 
>> 
>> 
>>> On 21 Nov 2019, at 09:50, Brian Trammell (IETF)  wrote:
>>> 
>>> Now with a better subject line, including coordinates.
>>> 
>>>> On 21 Nov 2019, at 08:46, Brian Trammell (IETF)  wrote:
>>>> 
>>>> ...and we've confirmed the IESG room reservation over lunchtime. It seems 
>>>> at least Michael and I will be there, please join if you can and we can 
>>>> all close some issues together.
>>>> 
>>>> Cheers,
>>>> 
>>>> Brian
>>>> 
>>>>> On 20 Nov 2019, at 23:34, Michael Welzl  wrote:
>>>>> 
>>>>>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF)  
>>>>>> wrote:
>>>>>> 
>>>>>> Greetings, all
>>>>>> 
>>>>>> The Friday time, it turns out, is less than ideal; I’ll have trouble 
>>>>>> showing up early enough to be useful and at least one other  author told 
>>>>>> me they’d have to bow out of a breakfast meeting to make it.
>>>>>> 
>>>>>> Jet lag, it’s a hell of a drug.
>>>>>> 
>>>>>> Short notice, I know, but would people be available for an authors’ 
>>>>>> meeting / editing session tomorrow (Thursday) over lunch? The idea is to 
>>>>>> bring food and meet in the IESG room (Mirja has offered to reserve it to 
>>>>>> us); if we can make good progress there, then we’re done. if not, I 
>>>>>> still have the Friday IAB room reservation.
>>>>> 
>>>>> Works fine for me
>>>>> 
>>>>> 
>>>>>> In either case the plan is to sit down and write, discussing suggested 
>>>>>> text and merging PRs to take advantage of higher bandwidth of everyone 
>>>>>> being here.
>>>>>> 
>>>>>> Thanks, cheers, and apologies for the organizational skill,
>>>>>> 
>>>>>> Brian 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF)  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Greetings, all,
>>>>>>> 
>>>>>>> We'll have a TAPS author's meeting (laptops open, writing PRs) from 
>>>>>>> 8:30 - 10:00 on Friday in the VIP B room at the venue (across from the 
>>>>>>> Olivia / Sophia rooms, since the signage is suboptimal).
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Brian
>>>>>> 
>>>>>> ___
>>>>>> 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
>> 
>> 
>> 
>> -- 
>> Colin Perkins
>> https://csperkins.org/
>> 
>> 
>> 
>> 
>> 
> 



-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room)

[Colin Perkins]

Sorry, I’m confused – is this moving to lunch today, rather than tomorrow 
morning?
Colin



> On 21 Nov 2019, at 09:50, Brian Trammell (IETF)  wrote:
> 
> Now with a better subject line, including coordinates.
> 
>> On 21 Nov 2019, at 08:46, Brian Trammell (IETF)  wrote:
>> 
>> ...and we've confirmed the IESG room reservation over lunchtime. It seems at 
>> least Michael and I will be there, please join if you can and we can all 
>> close some issues together.
>> 
>> Cheers,
>> 
>> Brian
>> 
>>> On 20 Nov 2019, at 23:34, Michael Welzl  wrote:
>>> 
>>>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF)  
>>>> wrote:
>>>> 
>>>> Greetings, all
>>>> 
>>>> The Friday time, it turns out, is less than ideal; I’ll have trouble 
>>>> showing up early enough to be useful and at least one other  author told 
>>>> me they’d have to bow out of a breakfast meeting to make it.
>>>> 
>>>> Jet lag, it’s a hell of a drug.
>>>> 
>>>> Short notice, I know, but would people be available for an authors’ 
>>>> meeting / editing session tomorrow (Thursday) over lunch? The idea is to 
>>>> bring food and meet in the IESG room (Mirja has offered to reserve it to 
>>>> us); if we can make good progress there, then we’re done. if not, I still 
>>>> have the Friday IAB room reservation.
>>> 
>>> Works fine for me
>>> 
>>> 
>>>> In either case the plan is to sit down and write, discussing suggested 
>>>> text and merging PRs to take advantage of higher bandwidth of everyone 
>>>> being here.
>>>> 
>>>> Thanks, cheers, and apologies for the organizational skill,
>>>> 
>>>> Brian 
>>>> 
>>>> 
>>>> 
>>>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF)  wrote:
>>>>> 
>>>>> Greetings, all,
>>>>> 
>>>>> We'll have a TAPS author's meeting (laptops open, writing PRs) from 8:30 
>>>>> - 10:00 on Friday in the VIP B room at the venue (across from the Olivia 
>>>>> / Sophia rooms, since the signage is suboptimal).
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Brian
>>>> 
>>>> ___
>>>> 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



-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] AD review of draft-ietf-taps-transport-security-08

[Colin Perkins]

Hi Magnus,

Responses to some of this inline.

> On 26 Sep 2019, at 09:01, Magnus Westerlund  
> wrote:
> 
> Hi,
>  
> Sorry about the delay in getting the AD review done. Below are my comments 
> and questions. Note the questions are truly questions and after answering we 
> can discuss if there needed to be any changes or not. 
>  
>  
> 1. Section 4.1: Is there a reason to use TLS 1.2 specification (RFC5246) 
> rather than TLS 1.3 as the general reference? 
>  
> 2. Comment on the writeup: Considering that ID nits results in the below 
> relevant references warning I would expect some comment in the writeup if 
> they are intentional. If not please update the references. If they are 
> intentional, please update the writeup to note them. 
>  
>  
>  
>   -- Obsolete informational reference (is this intentional?): RFC 2385
>  (Obsoleted by RFC 5925)
>  
>   -- Obsolete informational reference (is this intentional?): RFC 4474
>  (Obsoleted by RFC 8224)
>  
>   -- Obsolete informational reference (is this intentional?): RFC 5246
>  (Obsoleted by RFC 8446)
>  
>   -- Obsolete informational reference (is this intentional?): RFC 7539
>  (Obsoleted by RFC 8439)
>  
> 3.  Section 4.1.2: Is there a point to mention that TLS forward secrecy are 
> dependent on cipher suit for the key exchange and not ensured prior to 1.3? 
>  
> 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 1.3 
> draft: “(Note that this extension is only supported in
>DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)”
>  
> 5. Section 4.3.3: “QUIC transport relies on UDP.” Although QUIC is targeting 
> UDP as its main deployment vessel, isn’t QUIC in fact dependent on a 
> unreliable datagram service. But, maybe writing UDP is more straightforward?
>  
> 6. Section 4.5.4: When it comes to variants of SRTP. I think referencing RFC 
> 7201 would actually be reasonable, as in the many different options hide some 
> transport security options that so far is not discussed in this document. 
> Like securing multicasted / broadcasted RTP. 

Most of the additional security options described in RFC 7201 add little, if 
anything, to the other security protocols already discussed in the draft. We 
don’t mention that RTP can run over TLS over TCP, for example, but we already 
discuss TLS. The interesting protocol to mention is likely RTP with MIKEY for 
group communication, although bringing in group security might significantly 
widen the scope.

> 7. Section 4.5.4: So are ZRTP included as variant because it provides new 
> security features? Is that session continuity, or something else? 

The use of the short authentication string and key continuity.

> 8. Section 11: There are a number of references here that I don’t think meets 
> the requirement for references. These are the ones that only have a title and 
> n.d. All these could include a URL a date when these pages was visited and 
> contained the information you want to reference. 
>  
>  
> Cheers
>  
> Magnus Westerlund



-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] TAPS Sept 2019 Interim Scheduling

[Colin Perkins]

Likewise. And I’m also not convinced we’d make good use of an interim just now.

Colin



> On 17 Sep 2019, at 14:01, Brian Trammell (IETF)  wrote:
> 
> I've scheduled over that :(. can possibly reschedule now but would prefer 
> running another poll.
> 
> Cheers,
> 
> Brian
> 
>> On 17 Sep 2019, at 14:46, Aaron Falk  wrote:
>> 
>> Ugh, well it turns out that I’m moving on 9/27 and Zahed has a conflict. The 
>> doodle poll looked pretty good for Monday, 9/23. I know it’s short notice 
>> but are folks still available? If not, we’ll run another poll for a couple 
>> weeks later. Unless someone wants to chair the interim in our absence...
>> 
>> --aaron
>> 
>> On 9 Sep 2019, at 9:45, Aaron Falk wrote:
>> 
>> Actually, Friday, Sept 27, 11:00 AM – 1:00 PM EDT has the same availability 
>> and is slightly better for me. So, barring other strong objections (received 
>> real-soon-now), we’ll go with that. I’ll put in the request with the 
>> Secretariat.
>> 
>> Are there specific proposals for agenda topics?
>> 
>> --aaron
>> 
>> On 6 Sep 2019, at 11:21, Aaron Falk wrote:
>> 
>> Looks like Mon, Sept 23, 11:00 AM – 1:00 PM EDT is the likely candidate for 
>> an interim. If you want to attend and haven’t completed the doodle, please 
>> do so now.
>> 
>> Thanks,
>> 
>> --aaron
>> 
>> On 5 Sep 2019, at 16:41, Aaron Falk wrote:
>> 
>> We agreed in Montreal that we’d have a virtual meeting in September. Please 
>> complete the scheduling doodle below ASAP.
>> 
>> https://doodle.com/poll/msxgzyrv5b8ess3c
>> 
>> Best,
>> 
>> --aaron
>> 
>> ___
>> 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

Re: [Taps] ACTION REQUIRED: updating session conflicts

[Colin Perkins]

> On 19 Apr 2018, at 16:26, Aaron Falk  wrote:
> 
> Updated:
> 
> First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg 
> tls
> Second Priority: tcpinc mptcp saag mmusic tram irtfopen
> 

I have drafts in AVTCORE and RTCWEB, so it’d be good if they could be on the 
list.

-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] Which APIs are used by Applications that need low Latency? draft-mcquistin-taps-low-latency-services?

[Colin Perkins]

Hi Linda,

The key goal of the draft is to do a requirements analysis on the transport 
services needed for low-latency and real-time applications. The proposed 
abstract API is the minimal API to achieve this. The new API features, compared 
to the Sockets API, are those in Sections 3.4-3.6.

We have an experimental implementation of an API much like this, written as 
part of our TCP Hollywood work (https://csperkins.org/research/tcp-hollywood/). 
This is a research prototype, so there are no deployed applications using it. 

If you’re interested in the API work, the proposal in 
draft-trammell-post-sockets-00 is a more interesting, and radical, approach, 
and should also meet the requirements we outline.

Colin




> On 11 Nov 2016, at 10:01, Linda Dunbar  wrote:
> 
> Dear Authors, 
>  
> Your draft listed down several APIs. But which one is used by Applications 
> that need low latency?
>  
> Aren’t the “Socket Setup & Tear down” described in Section 3.1 the original 
> Berkley sockets APIs? If not, what are the differences?
>  
> How about the “getsocketopt” and “Setsockopt”?  and the APIs listed in 
> Section 3.3.?
>  
> Which APIs are used by Applications that need low Latency? 
>  
> Are there any Applications today using the APIs proposed in 
> draft-mcquistin-taps-low-latency-services?
>  
> Thank you very much, 
>  
> Linda Dunbar



-- 
Colin Perkins
https://csperkins.org/




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

[Taps] Fwd: I-D Action: draft-mcquistin-taps-low-latency-services-00.txt

[Colin Perkins]

Hi TAPS working group,

We’ve submitted draft-mcquistin-taps-low-latency-services-00 on “Transport 
Services for Low-Latency Real-Time Applications” which might be of interest. 
This expands on the presentation Stephen McQuistin gave to the TAPS group in 
IETF 96 in Berlin, and discusses the transport service requirements for 
low-latency real-time applications.

This is input to the TAPS process, and to the Post Sockets discussion. 

Comments appreciated! I’ll also be briefly presenting the work at IETF 97 in 
Seoul.

Cheers,
Colin




> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: I-D Action: draft-mcquistin-taps-low-latency-services-00.txt
> Date: 31 October 2016 at 10:24:19 GMT
> To: 
> Reply-To: internet-dra...@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : Transport Services for Low-Latency Real-Time 
> Applications
>Authors : Stephen McQuistin
>  Colin Perkins
>  Marwan Fayed
>   Filename: draft-mcquistin-taps-low-latency-services-00.txt
>   Pages   : 12
>   Date: 2016-10-31
> 
> Abstract:
>   This document describes the set of transport services required by
>   low-latency, real-time applications.  These services are derived from
>   the needs of the applications, rather than from the current
>   capabilities of the transport layer.  An example API, based on the
>   Berkeley Sockets API, is also provided, alongside examples of how the
>   target applications would use the API to access the transport
>   services described.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mcquistin-taps-low-latency-services/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-mcquistin-taps-low-latency-services-00
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Colin Perkins]

> On 20 Jul 2016, at 10:38, Michael Welzl  wrote:
> 
>> 
>> On 20. jul. 2016, at 10.27, Colin Perkins  wrote:
>> 
>>> On 19 Jul 2016, at 18:06, G Fairhurst  wrote:
>>> On 19/07/2016, 17:49, 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 after, which fits nicely.
>>>>>> 
>>>>>> Note, I phrased this controversial on purpose to generate a bit of list 
>>>>>> discussion: “abstracting away” something like usage of multiple paths 
>>>>>> should get some people to disagree?! Regarding the primitives we have so 
>>>>>> far, there doesn’t seem to be a compelling need for a TAPS system to 
>>>>>> expose them to an application I think.  (again, such abstraction always 
>>>>>> comes with loss of some control - at one end of this, you want to be in 
>>>>>> control of which transport protocol is used, which we don’t want here). 
>>>>>> Decisions need to be made...
>>>>>> 
>>>>>> 
>>>>>> Multi-streaming seems to me to be an easier case: I can’t see any reason 
>>>>>> why an application would need to be in control of this. Mapping 
>>>>>> communication channels between the same end hosts onto the same 
>>>>>> transport connection (whatever protocol provides it) should always be 
>>>>>> beneficial.
>>>>> I'm not sure I understand how an app can/should know about any of this.
>>>>> It strikes me as involving the app deep in "how" things are done in
>>>>> other layers, rather than indicating a preference on behavior it sees
>>>>> (it really shouldn't "see" any of this directly, IMO).
>>>>> 
>>>>> I.e., this would be a good place to take a lesson from QoS - the key is
>>>>> to indicate a preference to the net based on "application visible
>>>>> behavior", not to try to map things so directly based on semantics.
>>>> This sounds like a misunderstanding, maybe I didn’t make myself clear 
>>>> enough - because I think we agree:
>>>> an application can / should not know about any of this, IMO. It should 
>>>> just see a communication channel.
>>>> 
>>>> So mapping these channels onto a transport connection is what I thought a 
>>>> TAPS system underneath the application could do, and the application won’t 
>>>> need to be bothered.
>>>> 
>>>> Cheers,
>>>> Michael
>>> I can agree that applications should be encouraged to let the system figure 
>>> out how best to do these things.
>>> 
>>> A few applications will always want finer control (of QoS and flow 
>>> scheduling) - presumably because they believe they understand what they 
>>> actually need. I suggest even these apps can benefit from system-learned 
>>> information about what the network can actually offer.
>> 
>> Agree - exposing system-learned knowledge is clearly useful. I’m all for 
>> automating things where possible, but there are applications that can make 
>> use of additional knowledge to tune transport to better suit the 
>> application. Hide by default, sure, but allow tuning.
> 
> So in TAPS it seems to me that we’ll ALWAYS have someone saying “but there 
> can be a benefit if an application can do X, Y, Z”.
> And these always true statements. Everything that’s now there is there for a 
> reason, so whatever you remove will always come with an example of an 
> application that can make good use of it. In the end, we have the same API as 
> today and nothing has been achieved.

Surely you have a better API, with well-thought out hooks for tuning?

> So: sure a good TAPS API should allow applications to tune everything. Let’s 
> make this clear once and for all, for all things that we potentially 
> “automatize”, “hide” or whatever you to call it.
> 
> But: I do think the point here is to identify which things should be “hidden 
> by default” (to stay with your language, it doesn’t really matter what we 
> call it).

Agree. I’m just reacting to “you’re suggesting to *not* expose these transport 
services too? I’d agree” which suggests something a little different.

-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Colin Perkins]

> On 19 Jul 2016, at 18:06, G Fairhurst  wrote:
> On 19/07/2016, 17:49, 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 after, which fits nicely.
>>>> 
>>>> Note, I phrased this controversial on purpose to generate a bit of list 
>>>> discussion: “abstracting away” something like usage of multiple paths 
>>>> should get some people to disagree?! Regarding the primitives we have so 
>>>> far, there doesn’t seem to be a compelling need for a TAPS system to 
>>>> expose them to an application I think.  (again, such abstraction always 
>>>> comes with loss of some control - at one end of this, you want to be in 
>>>> control of which transport protocol is used, which we don’t want here). 
>>>> Decisions need to be made...
>>>> 
>>>> 
>>>> Multi-streaming seems to me to be an easier case: I can’t see any reason 
>>>> why an application would need to be in control of this. Mapping 
>>>> communication channels between the same end hosts onto the same transport 
>>>> connection (whatever protocol provides it) should always be beneficial.
>>> I'm not sure I understand how an app can/should know about any of this.
>>> It strikes me as involving the app deep in "how" things are done in
>>> other layers, rather than indicating a preference on behavior it sees
>>> (it really shouldn't "see" any of this directly, IMO).
>>> 
>>> I.e., this would be a good place to take a lesson from QoS - the key is
>>> to indicate a preference to the net based on "application visible
>>> behavior", not to try to map things so directly based on semantics.
>> This sounds like a misunderstanding, maybe I didn’t make myself clear enough 
>> - because I think we agree:
>> an application can / should not know about any of this, IMO. It should just 
>> see a communication channel.
>> 
>> So mapping these channels onto a transport connection is what I thought a 
>> TAPS system underneath the application could do, and the application won’t 
>> need to be bothered.
>> 
>> Cheers,
>> Michael
> I can agree that applications should be encouraged to let the system figure 
> out how best to do these things.
> 
> A few applications will always want finer control (of QoS and flow 
> scheduling) - presumably because they believe they understand what they 
> actually need. I suggest even these apps can benefit from system-learned 
> information about what the network can actually offer.

Agree - exposing system-learned knowledge is clearly useful. I’m all for 
automating things where possible, but there are applications that can make use 
of additional knowledge to tune transport to better suit the application. Hide 
by default, sure, but allow tuning.

-- 
Colin Perkins
https://csperkins.org/




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

Re: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31

[Colin Perkins]

Hi,

This draft is in good shape. Some quick comments, that are almost entirely 
editorial:

1, 2nd paragraph: RTP can also run over DCCP, TLS, and DTLS.

4.1.1: “described further in Section 3.1 below” – but section 3.1 is above in 
the document.

4.3 (SCTP): “It is therefore deployed in all Web browsers supporting WebRTC” – 
actually, a slightly restricted subset of SCTP tunnelled over DTLS over UDP is 
part of WebRTC.

4.6.2: editorial - list formatting is messed up

4.8.1: the correct expansion of RTCP is “RTP control protocol”, not “ Real Time 
Control Protocol”

4.8.1: “The RFC-series specifies RTP media formats” should be “…RTP payload 
formats”

4.8.1: “RTP sender and receiver can send RTCP report packets.” – actually, 
“…will send…”

4.8.2: “multicast, anycast or IPv4 broadcast” – not sure broadcast makes sense, 
and isn’t anycast just a variation on unicast? (i.e., RTP is no more anycast 
than is TCP)

5: RTP is not mentioned in the bullet lists of transport service features - 
should it be?

8: my name is mis-spelt in the bullet on section 4.8

Colin




> On 29 Dec 2015, at 17:22, Aaron Falk  wrote:
> 
> Reminder: WGLC on this doc ends this week.  Please read the current rev and 
> send comments -- pro or con -- to this list.
> 
> --aaron
> 
> On Tue, Dec 8, 2015 at 9:02 AM, Aaron Falk  <mailto:aaron.f...@gmail.com>> wrote:
> This email announces a TAPS Working Group Last Call (WGLC) on:
> 
> Services provided by IETF transport protocols and congestion control 
> mechanisms
> draft-ietf-taps-transports-08.txt 
> <https://datatracker.ietf.org/doc/draft-ietf-taps-transports/>
> 
> Due to the timing (many people take time off during the December holidays), 
> this WGLC will run for slightly longer than usual - it will be for just over 
> 3 weeks, ending at midnight US Eastern (daylight) Time on Thursday, December 
> 31st.  Comments should be sent to the taps@ietf.org <mailto:taps@ietf.org> 
> list, although purely editorial comments may be sent directly to the authors 
> (draft-ietf-taps-transpo...@ietf.org 
> <mailto:draft-ietf-taps-transpo...@ietf.org>).
> 
> We're looking for at least a couple more reviews during WGLC - please email 
> the chair (aaron.f...@gmail.com <mailto:aaron.f...@gmail.com>) if you're 
> interested and willing to review this draft (otherwise, we'll have to go 
> "beat the bushes" for reviewers).
> 
> Thanks, 
> 
> --aaron
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps



-- 
Colin Perkins
https://csperkins.org/




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