From nobody Thu Dec 21 10:10:11 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101AE1241F3 for ; Thu, 21 Dec 2017 10:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFPcHU6pz7sy for ; Thu, 21 Dec 2017 10:10:06 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB58312D77A for ; Thu, 21 Dec 2017 10:10:04 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id f2so33471895qtj.4 for ; Thu, 21 Dec 2017 10:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=YBbaz6VQzQQ7CbBlnM2jZ2PPgB0l2kDDUGc/IQx6Q6Q=; b=Q4kEro69yTTCMjnGBl730D4NGRrYe4t9mpeAAhZSiHfUdiEJiItmal8fAX31wMnYYl tQ1RolNiL2AGOrX8a9wr6FjbtkIoxpvPFkBWZopFdQu9uockchfzYb6FAI4MstKOuAtB vUaU7vFJf2N9AoJ6FaCdaP4ZS4UNYYMV27j9o9HgY1SxbrfX8Cdox7g/Bded1BCr1KvK yeXqz1OUPE7XAsYA78gPAUbZINcqzLk5m8jGsduLPkUFjOBUuuA+WzLQWelvmb+s6i3u mxnat27fe8skeQavmwsVdS1yKaUMZ24OKj2VxaDJFSwLHC+sBOUKgmu0SEizjMqwHbsz IrzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=YBbaz6VQzQQ7CbBlnM2jZ2PPgB0l2kDDUGc/IQx6Q6Q=; b=V/Z4OdtcGkdF3wJ8/2SCLWp2mbRmBu/zxRv/sjiH3vSc3NZ15JLBc1ptHpbGIgdWM6 mrKgVUQl90WPlTz2s++yeJu7j66IbRNcVRQGB5TRgRVmhQ8NNwT7/9aN/8V9+Pt8mJPa ELDf0PivU6BDqs68o4gPUkGljt6KCh0JwD/fMHnWKzqPf49U0pfk1OsAA3J7TrOFtpcl Kw8Cow/vUKkB8o7aFm46UP/uaS/xoksxyCNG9fLaGz4IzudRIUclC4bwBcEuW22ortc+ 4IlaAoPru0uK9Pa9Ogh5Ku3WIPeunjf2ZYK8CMDeGfdHVDVEQMQgTIeZlwkVGHa6Qca0 7X6A== X-Gm-Message-State: AKGB3mKiY6QvOdOFGS6NO9J+lUZZOxjhZASOM+Ug+ddok9a7zdqsJJZk h8dggoeE+mbmDyPd23qfEgx43xst X-Google-Smtp-Source: ACJfBovOnlvhNpFJWTdUgEaJD84HoEper94LttZtQjAxJNSJ4gWFynkksL45uxCIY3xkNwDu26oydQ== X-Received: by 10.200.6.4 with SMTP id d4mr16031480qth.15.1513879803184; Thu, 21 Dec 2017 10:10:03 -0800 (PST) Received: from [172.19.34.20] ([2601:184:4980:a321:e431:8f51:7a99:5611]) by smtp.gmail.com with ESMTPSA id q189sm2668272qkd.78.2017.12.21.10.10.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 10:10:02 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Thu, 21 Dec 2017 13:10:00 -0500 X-Mailer: MailMate (1.10r5443) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_F83A4F5B-5123-41A7-8FF8-96C29C2CD6B8_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] Draft TAPS minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 18:10:10 -0000 --=_MailMate_F83A4F5B-5123-41A7-8FF8-96C29C2CD6B8_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit We’re overdue for filing the minutes from our Singapore meeting. Please give the (very good) notes by Kyle & Tale a look and send comments. —aaron - - - - - TAPS IETF-100 Singapore Tuesday, November 14, 2017 Room: Olivia Minute takers: Kyle Rose tale 1. Chairs update - 10 min * Charter bashng * Chris, Aaron, Kyle agreed we need more precise charter language for the WG's transport security function. 2. draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min * Brian Trammell * Is this an API certification? * There's an implicit assumption of ordering in protocols based on number of features * From standpoint of feature set that you need to meet, that's the right way to think about it * Thinks doc is close to done * Tommy Pauly * Need to explicitly declare required features for a transport up-front * Remove all references to "fallback" because it implies a particular set of preferences/priorities that imply a total order * Instead, just catalog protocols by features provided and leave ordering to another doc * Spencer Dawkins (responsible AD) * Agrees with Tommy * Completeness * Aaron: What is required for document to be complete? * Michael: Tommy to proofread * Gabriel: Is CoAP supported? * Michael: Minset analysis based on a survey of important existing transport protocols * Aaron: Goal of minset is to identify minimum set of functions that a TAPS API should support to cover the basic set of functionality required by IETF protocols. If there's something missing from CoAP, maybe there's stuff in minset that shouldn't be there; alternatively, it may be that CoAP is not expressive enough to be usable through the TAPS API * Bob Moskovitz: Purpose of TAPS should be to disconnect the application from the details of the transport, whether or not a constrained transport <---this probably needs clarification * Tommy: (missed) * Mirja: How to map this to post-sockets? Anything that isn't related to connection establishment or data transfer should be separated out * Michael: "Maintenance" covers the configuration aspects of protocols * Tommy: Pieces of functionality that are core transport functionality, and then protocol-specific (or model-specific) things that need to be separated out * Michael: Need to distinguish between what needs to be said up-front, but I don't like the idea of separating out core functionality from non-core * Mirja: There is a box called "configuration" in post-sockets. We need to know what goes in there. * Brian: There are things you need to do during connection setup that can't be changed without tearing down connection state: not maintenance. Is this an API specification? It's a specification for APIs that implement TAPS. Would be useful if the knobs available here were organized in a better way. May just need to add another layer to express additional configuration. 3. draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 min * Brian Trammel * Hard requirement that the protocol stack configuration work without a requirement that a bunch of config be provided. * "Configuration" box is what you use to constrain the magic protocol configuration state maintained for a path in the association. * Obviate the need for dicking around with sockopts because the defaults are saner. * Tommy Pauly * *IF* you use TCP, set this option; *IF* you choose SCTP, do this. Extra knobs if you need something very specific. * Noted another change in the draft is around messages; we like the message abstraction but need to understand how that relates to streams and chunking * Praveen from Microsoft * How do you reconcile system configuration with app configuration(? not sure I got that right) * Brian: the jokey answers is that it sort of looks like cascading style sheets, using predictable overrides to get a final instance configuration. hope to do better than CSS * Kyle Rose * Re predictability and "too much magic" making things hard to figure out with regard to performance targets etc * Brian: Yes really, let's talk about this offline because it'll be like a half hour discussion * Accessability of specific aspects of different transport protocol features (maybe non-obvious requirements, like degrading perf on purpose for testing purposes) * Brian: the intention is to make it all available through the API if you know which one you're working with * Brian * Open issues: * a protocol-independent carrier state machine * how to represent certain transport-specific interactions * Bring this into the wg now? * critical mass of Abstract interface proposals now * ready to take the creative leap to design the API * Aaron: actually this does sound like a charter change for architecture * name?: In a way this is looking at "maxset" rather than "minset" * Michael Wetzl: the reason the charter is so conservative was because people couldn't really agree so had to be pared down. Agree that it is good to have a higher layer, but concerned about the implementability * Aaron: moving into the territory of a charter revision, which we're not going to talk about right now. mic closed. 5. draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 min * Automated Transport Option Selection (see slides) * Desire to use same set of (essential) keywords no matter what programming language is being used * Main questions: is this easy enough and useful enough to devs? sufficient to express the usual set of intents? what's missing? * Michael Wetzl: * could be missing out some things that might not be obvious from looking at current protocols * ?: * How to app dev really know how to understand things like the implications of burstiness? or what bitrates it is using? * Philip: An app should have a fairly intuitive understanding of whether it is constant or bursty, even if it doesn't know the specifics of volume * Praveen: * Think it really needs some way of indicating the pattern of traffic (eg, send/receive messages) * Philip: +1 * Tommy: * Very difficult area to get right; we're going to need to expose the protocol knobs * Definitely want to see this discussion happening in the WG even if this particular set of options is torn down. Expect it to be a tricky, difficult discussion * Aaron Falk: * Have you implemented it? * Philip: limited implementation on top of BSD Sockets * This does go back to the ATM classification discussions and previous attempts to categorize what is expected of the network * This table is an "attractive nuisance" for criticism and a good starting point * Philip: agreed, it is just a starting point and not being proposed as the end point * ? * The table worries me because it seems far to easy to rathole on each element of it * Aaron: are there semantics from the ABT world that would be useful? * ? * An issue in the table that "intents" are about things the app is signalling what it intends to do, but other things there are not really intents but something the app desires * It isn't useful for apps to just only be able to say "give me all the best performance always" but rather to have to indicate what the trade-offs are * Mirja Kuhlewind: * Agree with ?previous speaker. Not really sure what does make sense to specify here. * Brian: * "Can you go back to the ATM table [slide] again?" * Two main issues with this; the further right you get the happier I am and to the left the sadder. It's sort of like a heat map of how I like the table. * Table helped clarify for me the separations that are needed * Two distincts groups of people in this room, apps chauvanists and transport chauvinists, and these are in tension for designing the architecture. really need to find the balance. * This way is application chauvanist (and I'm [Brian] also application chauvanist) but we need to call that out * David Schinazi * Another type of chauvanist, an engineering chauvanist, which I am * Definitely value in some sort of registry for different types of intents and showing how they could be used * Premature to have a laundry list of all the things we might possibly want without an understanding of how we really want to use them (like burstiness) * Gorry Fairhurst: * I like the list; I think the list should be bigger, but the datatype values should mostly be binary (enums) * Philip: * Open question: is this the way the IETF describes Abstract APIs? 4. draft-pauly-taps-guidelines-01 - Tommy Pauly, Apple -25 min * See slides, on the topic of racing connections * Tommy ... didn't even get off the title slide before Colin was @ the mic * Colin * Scoping question: when you say racing do you mean Happy Eyeballs or things like ICE as well? * Tommy: mostly from Happy Eyeballs perspective * Aaron: * Is split VPN definining separate peths? * Tommy: conceptually yes * Colin * Trying to still figure out the difference between a path and endpoints * ICE is about determing what works * Tommy: which yes is also what this about, and we do need more work w/ICE * Brian * (on Avoiding Ossification slide) these things seem to be mutually exclusive but maybe not intrinstically so but rather in your approach. not sure how to fix it though. * Tommy: in the context of the current app dev cycle, taps is way better than BSD sockets api used to be, way easier to just turn on a bit than change the whole model * Re what should be raced or not raced, advantages to doing it tree oriented rather than sequence oriented * Colin * On the ossification point, in the past we were trying to be general (SOCK_STREAM) but never really was, whereas we do avoid some of that with taps by already starting with more than one underlying choice * Wolfgang Beck * It is interesting that most (all?) IETF docs that talk about what protocol an app should use never talk about general charateristics like stream/dgram but rather specifically call out TCP or UDP * Colin * Quick followup on the ICE point, you may have to hook this racing into the application state * Spencer * Interested in the comments about modern dev cycles vs historic, and would like this explored more before last call * Tommy: the tail of people who are not pushing new updates to their code are probably not going to adopting anything beyond BSD sockets anyway 6. draft-fairhurst-taps-neat-00, Gorry Fairhurst, University of Aberdeen -20 min * See slides * Zahed: Who is setting up the policy? * Gorry: Internal interface in neat, from the policy manager * Personally pefer binary keywords for desired characteristics, like "low latency", over specific metrics * Slight concerns about making things overly complicated into the neat api * Strongly believe taps API has to be callback based to support the expected mechanisms of the current app dev world * Aaron * Can you say anything about the example apps? * Gorry: well we can send bytes backwards and forwards, so that's good right? And Mozilla has something working with it * Mirja * The base architecture should be a message not a stream * Gorry: totally agree with you * Still some fuzziness around transport/session layer * Kyle * Minor quibble on making it event driven, because sometimes you don't really want to use that style (maybe using imperative/blocking, maybe using CPS) * What you want is the API to express various programming models, maybe with the event-based model as the foundation for others if it's sufficiently expressive to capture all widely-used models * Gorry: system is based on libuv, and yes maybe we could do other models on top of that as the substrate * Tommy * We definitely don't want blocking to be the main API but there are multiple models for asynchronousity * Abstract API should absolutely not have anything specific about how to implement it, just the features needed * Wolfgang Beck * ? ... sorry missed that first comment (so did I) * Issues about limiting th queue size is not that useful without understanding other issues w.r.t rate / etc. What we really want is more like the Van Jacobsen model with something like packet soldiers(?) * Gorry: you're a realtime person, aren't you? * Yes so coming from that perspective * Zahed * Gorry: See happy eyeballs as "how do you decide on a final transport?" But then you have the problem of choosing the candidates, and that's the bit where the policy engine(?) fits in. * Gorry * Deciding on an architecture will help a lot with nailing down terminology 7. Discussion on charter item 3 - 10 min * Aaron * Look at the history of the group, and how the possibility of rechartering was considered early on based on initial results * Aaron's feelig the love * Let the record show: Aaron is happy. * My gut tells me that there is a useful common architecture can be extracted from this. What does the group think? * Brian Trammel * We basically do have some architectures, so can be chosing to continue that as wg business. Like postsockets is an architecture * Aaron: I would be pleased to hear whether the people who work on other projects (neat) would be good with working with that * Mirja * The different projects have different levels of abstraction, so we should be deciding on what level of abstraction to use * Should pursue as unified, not two separate abstraction layers * Michael * Essential agreement with Mirja * Aaron: implementation experience is extremely valuable for validating these ideas * Gorry * Not incompatible; just different levels * Anna * Neat is not abstract enough but postsockets probably too abstract, would be good to find something in the middle * Tommy * We have enough experience in the room with various implementations. Agree this is at a very abstract level. There's a neat implementation doc saying "this is how we decided to implement it". I could produce one of those also for how we (Apple) implemented it. * What I want to see out of postsockets is something that is forward looking enough to still be relevant in 10 years but still implementable now * --over time-- * Mirja * Phillip * Good to see that postsockets/neat is moving toward a common language and want to keep them separate for now to see how they might naturally come together over time * Tommy * One thing that could help speed up that coming together is a terminoogy document to solidify that common language (eg, to define what a path is, etc) * Aaron thinks the bar is low for defining terminology. Aaron is apparently new to the IETF --fin --=_MailMate_F83A4F5B-5123-41A7-8FF8-96C29C2CD6B8_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

We=E2=80=99re overdue for filing the minutes from our Sin= gapore meeting. Please give the (very good) notes by Kyle & Tale a l= ook and send comments.

=E2=80=94aaron

TAPS
IETF-100 Singapore
Tuesday, November 14, 2017
Room: Olivia

Minute takers:
Kyle Rose
tale

  1. Chairs update - 10 min

    • Charter bashng
      • Chris, Aaron, Kyle agreed we need more precise charter language for t= he WG's transport security function.

  2. draft-ietf-taps-minset-00 - Michael Wizel= , University of Oslo -15 min

    • Brian Trammell
      • Is this an API certification? <laugh>
      • There's an implicit assumption of ordering in protocols based on numb= er of features
      • From standpoint of feature set that you need to meet, that's the righ= t way to think about it
      • Thinks doc is close to done
    • Tommy Pauly
      • Need to explicitly declare required features for a transport up-front=
      • Remove all references to "fallback" because it implies a particular s= et of preferences/priorities that imply a total order
      • Instead, just catalog protocols by features provided and leave orderi= ng to another doc
    • Spencer Dawkins (responsible AD)
      • Agrees with Tommy
    • Completeness
      • Aaron: What is required for document to be complete?
      • Michael: Tommy to proofread
      • Gabriel: Is CoAP supported?
      • Michael: Minset analysis based on a survey of important existing tran= sport protocols
      • Aaron: Goal of minset is to identify minimum set of functions that a = TAPS API should support to cover the basic set of functionality required = by IETF protocols. If there's something missing from CoAP, maybe there's = stuff in minset that shouldn't be there; alternatively, it may be that Co= AP is not expressive enough to be usable through the TAPS API
      • Bob Moskovitz: Purpose of TAPS should be to disconnect the applicatio= n from the details of the transport, whether or not a constrained transpo= rt <---this probably needs clarification
      • Tommy: (missed)
      • Mirja: How to map this to post-sockets? Anything that isn't related t= o connection establishment or data transfer should be separated out
      • Michael: "Maintenance" covers the configuration aspects of protocols<= /li>
      • Tommy: Pieces of functionality that are core transport functionality,= and then protocol-specific (or model-specific) things that need to be se= parated out
      • Michael: Need to distinguish between what needs to be said up-front, = but I don't like the idea of separating out core functionality from non-c= ore
      • Mirja: There is a box called "configuration" in post-sockets. We need= to know what goes in there.
      • Brian: There are things you need to do during connection setup that c= an't be changed without tearing down connection state: not maintenance. I= s this an API specification? It's a specification for APIs that implement= TAPS. Would be useful if the knobs available here were organized in a be= tter way. May just need to add another layer to express additional config= uration.

  3. draft-trammell-taps-post-sockets-03, Bria= n Trammell, ETH Zurich - 20 min

    • Brian Trammel
      • Hard requirement that the protocol stack configuration work without a= requirement that a bunch of config be provided.
      • "Configuration" box is what you use to constrain the magic protocol c= onfiguration state maintained for a path in the association.
      • Obviate the need for dicking around with sockopts because the default= s are saner.
    • Tommy Pauly
      • IF you use TCP, set this option; IF you choose SCTP= , do this. Extra knobs if you need something very specific.
      • Noted another change in the draft is around messages; we like the mes= sage abstraction but need to understand how that relates to streams and c= hunking
    • Praveen from Microsoft
      • How do you reconcile system configuration with app configuration(? no= t sure I got that right)
      • Brian: the jokey answers is that it sort of looks like cascading styl= e sheets, using predictable overrides to get a final instance configurati= on. hope to do better than CSS
    • Kyle Rose
      • Re predictability and "too much magic" making things hard to figure o= ut with regard to performance targets etc
        • Brian: Yes really, let's talk about this offline because it'll be lik= e a half hour discussion
      • Accessability of specific aspects of different transport protocol fea= tures (maybe non-obvious requirements, like degrading perf on purpose for= testing purposes)
        • Brian: the intention is to make it all available through the API if y= ou know which one you're working with
    • Brian
      • Open issues: =
        • a protocol-independent carrier state machine
        • how to represent certain transport-specific interactions
      • Bring this into the wg now?
        • critical mass of Abstract interface proposals now
        • ready to take the creative leap to design the API
        • Aaron: actually this does sound like a charter change for architectu= re
        • name?: In a way this is looking at "maxset" rather than "minset"
          • =
        • Michael Wetzl: the reason the charter is so conservative was because = people couldn't really agree so had to be pared down. Agree that it is g= ood to have a higher layer, but concerned about the implementability
          • =
        • Aaron: moving into the territory of a charter revision, which we're n= ot going to talk about right now. mic closed.

  4. draft-tiesel-taps-socketintents-01, Phili= pp S. Tiesel, TU Berlin - 20 min

    • Automated Transport Option Selection (see slides)
    • Desire to use same set of (essential) keywords no matter what program= ming language is being used
    • Main questions: is this easy enough and useful enough to devs? suffi= cient to express the usual set of intents? what's missing?
    • Michael Wetzl:
      • could be missing out some things that might not be obvious from looki= ng at current protocols
    • ?: =
      • How to app dev really know how to understand things like the implicat= ions of burstiness? or what bitrates it is using?
      • Philip: An app should have a fairly intuitive understanding of whethe= r it is constant or bursty, even if it doesn't know the specifics of volu= me
    • Praveen:
      • Think it really needs some way of indicating the pattern of traffic (= eg, send/receive messages)
      • Philip: +1
    • Tommy:
      • Very difficult area to get right; we're going to need to expose the p= rotocol knobs
      • Definitely want to see this discussion happening in the WG even if th= is particular set of options is torn down. Expect it to be a tricky, dif= ficult discussion
    • Aaron Falk:
      • Have you implemented it?
      • Philip: limited implementation on top of BSD Sockets
      • This does go back to the ATM classification discussions and previous = attempts to categorize what is expected of the network
      • This table is an "attractive nuisance" for criticism and a good start= ing point
      • Philip: agreed, it is just a starting point and not being proposed as= the end point
    • ?
      • The table worries me because it seems far to easy to rathole on each = element of it
      • Aaron: are there semantics from the ABT world that would be useful?
    • ?
      • An issue in the table that "intents" are about things the app is sign= alling what it intends to do, but other things there are not really inten= ts but something the app desires
      • It isn't useful for apps to just only be able to say "give me all the= best performance always" but rather to have to indicate what the trade-o= ffs are
    • Mirja Kuhlewind:
      • Agree with ?previous speaker. Not really sure what does make sense t= o specify here.
    • Brian:
      • "Can you go back to the ATM table [slide] again?"
      • Two main issues with this; the further right you get the happier I am= and to the left the sadder. It's sort of like a heat map of how I like = the table.
      • Table helped clarify for me the separations that are needed
      • Two distincts groups of people in this room, apps chauvanists and tra= nsport chauvinists, and these are in tension for designing the architectu= re. really need to find the balance.
      • This way is application chauvanist (and I'm [Brian] also application = chauvanist) but we need to call that out
    • David Schinazi
      • Another type of chauvanist, an engineering chauvanist, which I am
      • Definitely value in some sort of registry for different types of inte= nts and showing how they could be used
      • Premature to have a laundry list of all the things we might possibly = want without an understanding of how we really want to use them (like bur= stiness)
    • Gorry Fairhurst:
      • I like the list; I think the list should be bigger, but the datatype = values should mostly be binary (enums)
    • Philip:
      • Open question: is this the way the IETF describes Abstract APIs?
        • =

  5. draft-pauly-taps-guidelines-01 - Tommy Pa= uly, Apple -25 min

    • See slides, on the topic of racing connections
    • Tommy ... didn't even get off the title slide before Colin was @ the = mic
    • Colin
      • Scoping question: when you say racing do you mean Happy Eyeballs or t= hings like ICE as well?
      • Tommy: mostly from Happy Eyeballs perspective
    • Aaron:
      • Is split VPN definining separate peths?
      • Tommy: conceptually yes
    • Colin
      • Trying to still figure out the difference between a path and endpoint= s
      • ICE is about determing what works
      • Tommy: which yes is also what this about, and we do need more work w/= ICE
    • Brian
      • (on Avoiding Ossification slide) these things seem to be mutually exc= lusive but maybe not intrinstically so but rather in your approach. not = sure how to fix it though.
      • Tommy: in the context of the current app dev cycle, taps is way bett= er than BSD sockets api used to be, way easier to just turn on a bit than= change the whole model
      • Re what should be raced or not raced, advantages to doing it tree ori= ented rather than sequence oriented
    • Colin
      • On the ossification point, in the past we were trying to be general (= SOCK_STREAM) but never really was, whereas we do avoid some of that with = taps by already starting with more than one underlying choice
    • Wolfgang Beck
      • It is interesting that most (all?) IETF docs that talk about what pro= tocol an app should use never talk about general charateristics like stre= am/dgram but rather specifically call out TCP or UDP
    • Colin
      • Quick followup on the ICE point, you may have to hook this racing int= o the application state
    • Spencer
      • Interested in the comments about modern dev cycles vs historic, and w= ould like this explored more before last call
      • Tommy: the tail of people who are not pushing new updates to their co= de are probably not going to adopting anything beyond BSD sockets anyway<= /li>

  6. draft-fairhurst-taps-neat-00, Gorry Fairh= urst, University of Aberdeen -20 min

    • See slides
    • Zahed: Who is setting up the policy?
    • Gorry: Internal interface in neat, from the policy manager
    • Personally pefer binary keywords for desired characteristics, like "l= ow latency", over specific metrics
    • Slight concerns about making things overly complicated into the neat = api
    • Strongly believe taps API has to be callback based to support the exp= ected mechanisms of the current app dev world
    • Aaron
      • Can you say anything about the example apps?
      • Gorry: well we can send bytes backwards and forwards, so that's good= right? And Mozilla has something working with it
    • Mirja
      • The base architecture should be a message not a stream
      • Gorry: totally agree with you
      • Still some fuzziness around transport/session layer
    • Kyle
      • Minor quibble on making it event driven, because sometimes you don't = really want to use that style (maybe using imperative/blocking, maybe usi= ng CPS)
      • What you want is the API to express various programming models, maybe= with the event-based model as the foundation for others if it's sufficie= ntly expressive to capture all widely-used models
      • Gorry: system is based on libuv, and yes maybe we could do other mode= ls on top of that as the substrate
    • Tommy
      • We definitely don't want blocking to be the main API but there are mu= ltiple models for asynchronousity
      • Abstract API should absolutely not have anything specific about how t= o implement it, just the features needed
    • Wolfgang Beck
      • ? ... sorry missed that first comment (so did I)
      • Issues about limiting th queue size is not that useful without unders= tanding other issues w.r.t rate / etc. What we really want is more like = the Van Jacobsen model with something like packet soldiers(?)
      • Gorry: you're a realtime person, aren't you?
      • Yes so coming from that perspective
    • Zahed
      • Gorry: See happy eyeballs as "how do you decide on a final transport?= " But then you have the problem of choosing the candidates, and that's th= e bit where the policy engine(?) fits in.
    • Gorry
      • Deciding on an architecture will help a lot with nailing down termino= logy

  7. Discussion on charter item 3 - 10 min

    =
    • Aaron
      • Look at the history of the group, and how the possibility of recharte= ring was considered early on based on initial results
      • Aaron's feelig the love
      • Let the record show: Aaron is happy.
      • My gut tells me that there is a useful common architecture can be ext= racted from this. What does the group think?
    • Brian Trammel
      • We basically do have some architectures, so can be chosing to continu= e that as wg business. Like postsockets is an architecture
      • Aaron: I would be pleased to hear whether the people who work on othe= r projects (neat) would be good with working with that
    • Mirja
      • The different projects have different levels of abstraction, so we sh= ould be deciding on what level of abstraction to use
      • Should pursue as unified, not two separate abstraction layers
    • Michael
      • Essential agreement with Mirja
      • Aaron: implementation experience is extremely valuable for validating= these ideas
    • Gorry
      • Not incompatible; just different levels
    • Anna
      • Neat is not abstract enough but postsockets probably too abstract, wo= uld be good to find something in the middle
    • Tommy
      • We have enough experience in the room with various implementations. A= gree this is at a very abstract level. There's a neat implementation doc = saying "this is how we decided to implement it". I could produce one of t= hose also for how we (Apple) implemented it.
      • What I want to see out of postsockets is something that is forward lo= oking enough to still be relevant in 10 years but still implementable now=
    • --over time--
    • Mirja
    • Phillip
      • Good to see that postsockets/neat is moving toward a common language = and want to keep them separate for now to see how they might naturally co= me together over time
    • Tommy
      • One thing that could help speed up that coming together is a terminoo= gy document to solidify that common language (eg, to define what a path i= s, etc)
    • Aaron thinks the bar is low for defining terminology. Aaron is appar= ently new to the IETF

--fin

--=_MailMate_F83A4F5B-5123-41A7-8FF8-96C29C2CD6B8_=-- From nobody Wed Dec 27 09:18:44 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2012702E for ; Wed, 27 Dec 2017 09:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POmcPuTjL8Fo for ; Wed, 27 Dec 2017 09:18:39 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9931A1242EA for ; Wed, 27 Dec 2017 09:18:39 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id w10so48528145qtb.10 for ; Wed, 27 Dec 2017 09:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2JWm3L857jD7NcuLR7GKVqFWwtevfDQGE7RLtWSChrc=; b=GYovzCzndCLT/4O/QUlPB6ZIsx+gtXkjQzcZesGrLy1i2xabb9qC5XjfwhXXloLIFj A+QJAtOxtNAd48neUrotAWbJOq4KsIPqiz4TZeo9Ffh98rsVigr4XiShPQENSYzgVy3m aWaJtR8XB5eOapccFFOjTOa2ClAz1701TS2kHT+cYdFbeM7GPWMyhrb+HHCxLOgD7/IA nyLOOdcMMcx8z7FKwIDYUupJOuhIK/jmLvl7OXrYeeR+noOTk/mywBlgX9emNMnYJZQW TVKatmhq43NOwxtFLPFbe1SrmOEkpbDHKnv/FOElzA4PpCBJUg8X67mZdkGI1RRuN0mV 0QCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2JWm3L857jD7NcuLR7GKVqFWwtevfDQGE7RLtWSChrc=; b=k9U8WCvg/gC1tmO8f4Nl0njcwXhVJi3aCvuiu5X07o9AaylOf83P0hoegkOQRpZ62G tdFVcsRDSO/LacWDtgTS81Dkx8b2IN15IE48eqZO2K/VKEAUEIvVoDJjfc0fNTKaW2Y8 ILLU+dUXPnATAOREUt/4FkCgslCG2qga96KSdOM7KnYw1u03utvd7Rlftf+pRMB+7WsX T1u0vuouxuJgx+xGVLMGio0LHhFEFYDbFsslNgRG28drr2VLd9+PVU95+kZNH1gOonUM ZUSC2Pixd774g6ATA9j/zPgPa+PllmeHj14PpVSJoByGQxliKyHWv+bU7M/oLPcNODz8 DdRQ== X-Gm-Message-State: AKGB3mJJx+h2T5+n0MoBVNZwVD5ntFElcbjGFu+R1ZGlAOKLDYLzdQyg +Yccw4vuQclVm6VDcLXMov9PIJGvw1qS5kBRGDY= X-Google-Smtp-Source: ACJfBou422J98C7fks8nXbENpye9XoIcRGN+tpwPZKuTy2qnNo78Hoob8qnKSoFwI9zmjbwJUp5mUQEL2wKn6wishUE= X-Received: by 10.200.44.251 with SMTP id 56mr39030091qtx.87.1514395118470; Wed, 27 Dec 2017 09:18:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Wed, 27 Dec 2017 17:18:28 +0000 Message-ID: To: Aaron Falk Cc: taps WG Content-Type: multipart/alternative; boundary="001a11404b84160b0e05615597ad" Archived-At: Subject: Re: [Taps] Draft TAPS minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 17:18:43 -0000 --001a11404b84160b0e05615597ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IIRC the person marked as ? in the draft-tiesel-taps-socketintents-01 slot was Nacho Solis. Best, Chris On Thu, Dec 21, 2017 at 10:10 AM Aaron Falk wrote: > We=E2=80=99re overdue for filing the minutes from our Singapore meeting. = Please > give the (very good) notes by Kyle & Tale a look and send comments. > > =E2=80=94aaron > ------------------------------ > > TAPS > IETF-100 Singapore > Tuesday, November 14, 2017 > Room: Olivia > > Minute takers: > Kyle Rose > tale > > 1. > > Chairs update - 10 min > - Charter bashng > - Chris, Aaron, Kyle agreed we need more precise charter > language for the WG's transport security function. > 2. > > draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min > - Brian Trammell > - Is this an API certification? > - There's an implicit assumption of ordering in protocols based > on number of features > - From standpoint of feature set that you need to meet, that's > the right way to think about it > - Thinks doc is close to done > - Tommy Pauly > - Need to explicitly declare required features for a transport > up-front > - Remove all references to "fallback" because it implies a > particular set of preferences/priorities that imply a total orde= r > - Instead, just catalog protocols by features provided and leave > ordering to another doc > - Spencer Dawkins (responsible AD) > - Agrees with Tommy > - Completeness > - Aaron: What is required for document to be complete? > - Michael: Tommy to proofread > - Gabriel: Is CoAP supported? > - Michael: Minset analysis based on a survey of important > existing transport protocols > - Aaron: Goal of minset is to identify minimum set of functions > that a TAPS API should support to cover the basic set of functio= nality > required by IETF protocols. If there's something missing from Co= AP, maybe > there's stuff in minset that shouldn't be there; alternatively, = it may be > that CoAP is not expressive enough to be usable through the TAPS= API > - Bob Moskovitz: Purpose of TAPS should be to disconnect the > application from the details of the transport, whether or not a = constrained > transport <---this probably needs clarification > - Tommy: (missed) > - Mirja: How to map this to post-sockets? Anything that isn't > related to connection establishment or data transfer should be s= eparated out > - Michael: "Maintenance" covers the configuration aspects of > protocols > - Tommy: Pieces of functionality that are core transport > functionality, and then protocol-specific (or model-specific) th= ings that > need to be separated out > - Michael: Need to distinguish between what needs to be said > up-front, but I don't like the idea of separating out core funct= ionality > from non-core > - Mirja: There is a box called "configuration" in post-sockets. > We need to know what goes in there. > - Brian: There are things you need to do during connection setup > that can't be changed without tearing down connection state: not > maintenance. Is this an API specification? It's a specification = for APIs > that implement TAPS. Would be useful if the knobs available here= were > organized in a better way. May just need to add another layer to= express > additional configuration. > 3. > > draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 > min > - Brian Trammel > - Hard requirement that the protocol stack configuration work > without a requirement that a bunch of config be provided. > - "Configuration" box is what you use to constrain the magic > protocol configuration state maintained for a path in the associ= ation. > - Obviate the need for dicking around with sockopts because the > defaults are saner. > - Tommy Pauly > - *IF* you use TCP, set this option; *IF* you choose SCTP, do > this. Extra knobs if you need something very specific. > - Noted another change in the draft is around messages; we like > the message abstraction but need to understand how that relates = to streams > and chunking > - Praveen from Microsoft > - How do you reconcile system configuration with app > configuration(? not sure I got that right) > - Brian: the jokey answers is that it sort of looks like > cascading style sheets, using predictable overrides to get a fin= al instance > configuration. hope to do better than CSS > - Kyle Rose > - Re predictability and "too much magic" making things hard to > figure out with regard to performance targets etc > - Brian: Yes really, let's talk about this offline because > it'll be like a half hour discussion > - Accessability of specific aspects of different transport > protocol features (maybe non-obvious requirements, like degradin= g perf on > purpose for testing purposes) > - Brian: the intention is to make it all available through > the API if you know which one you're working with > - Brian > - Open issues: > - a protocol-independent carrier state machine > - how to represent certain transport-specific interactions > - Bring this into the wg now? > - critical mass of Abstract interface proposals now > - ready to take the creative leap to design the API > - Aaron: actually this does sound like a charter change for > architecture > - name?: In a way this is looking at "maxset" rather than > "minset" > - Michael Wetzl: the reason the charter is so conservative > was because people couldn't really agree so had to be pared d= own. Agree > that it is good to have a higher layer, but concerned about t= he > implementability > - Aaron: moving into the territory of a charter revision, > which we're not going to talk about right now. mic closed. > 4. > > draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 > min > - Automated Transport Option Selection (see slides) > - Desire to use same set of (essential) keywords no matter what > programming language is being used > - Main questions: is this easy enough and useful enough to devs? > sufficient to express the usual set of intents? what's missing? > - Michael Wetzl: > - could be missing out some things that might not be obvious from > looking at current protocols > - ?: > - How to app dev really know how to understand things like the > implications of burstiness? or what bitrates it is using? > - Philip: An app should have a fairly intuitive understanding of > whether it is constant or bursty, even if it doesn't know the sp= ecifics of > volume > - Praveen: > - Think it really needs some way of indicating the pattern of > traffic (eg, send/receive messages) > - Philip: +1 > - Tommy: > - Very difficult area to get right; we're going to need to > expose the protocol knobs > - Definitely want to see this discussion happening in the WG > even if this particular set of options is torn down. Expect it t= o be a > tricky, difficult discussion > - Aaron Falk: > - Have you implemented it? > - Philip: limited implementation on top of BSD Sockets > - This does go back to the ATM classification discussions and > previous attempts to categorize what is expected of the network > - This table is an "attractive nuisance" for criticism and a > good starting point > - Philip: agreed, it is just a starting point and not being > proposed as the end point > - ? > - The table worries me because it seems far to easy to rathole > on each element of it > - Aaron: are there semantics from the ABT world that would be > useful? > - ? > - An issue in the table that "intents" are about things the app > is signalling what it intends to do, but other things there are = not really > intents but something the app desires > - It isn't useful for apps to just only be able to say "give me > all the best performance always" but rather to have to indicate = what the > trade-offs are > - Mirja Kuhlewind: > - Agree with ?previous speaker. Not really sure what does make > sense to specify here. > - Brian: > - "Can you go back to the ATM table [slide] again?" > - Two main issues with this; the further right you get the > happier I am and to the left the sadder. It's sort of like a hea= t map of > how I like the table. > - Table helped clarify for me the separations that are needed > - Two distincts groups of people in this room, apps chauvanists > and transport chauvinists, and these are in tension for designin= g the > architecture. really need to find the balance. > - This way is application chauvanist (and I'm [Brian] also > application chauvanist) but we need to call that out > - David Schinazi > - Another type of chauvanist, an engineering chauvanist, which I > am > - Definitely value in some sort of registry for different types > of intents and showing how they could be used > - Premature to have a laundry list of all the things we might > possibly want without an understanding of how we really want to = use them > (like burstiness) > - Gorry Fairhurst: > - I like the list; I think the list should be bigger, but the > datatype values should mostly be binary (enums) > - Philip: > - Open question: is this the way the IETF describes Abstract > APIs? > 5. > > draft-pauly-taps-guidelines-01 - Tommy Pauly, Apple -25 min > - See slides, on the topic of racing connections > - Tommy ... didn't even get off the title slide before Colin was @ > the mic > - Colin > - Scoping question: when you say racing do you mean Happy > Eyeballs or things like ICE as well? > - Tommy: mostly from Happy Eyeballs perspective > - Aaron: > - Is split VPN definining separate peths? > - Tommy: conceptually yes > - Colin > - Trying to still figure out the difference between a path and > endpoints > - ICE is about determing what works > - Tommy: which yes is also what this about, and we do need more > work w/ICE > - Brian > - (on Avoiding Ossification slide) these things seem to be > mutually exclusive but maybe not intrinstically so but rather in= your > approach. not sure how to fix it though. > - Tommy: in the context of the current app dev cycle, taps is > way better than BSD sockets api used to be, way easier to just t= urn on a > bit than change the whole model > - Re what should be raced or not raced, advantages to doing it > tree oriented rather than sequence oriented > - Colin > - On the ossification point, in the past we were trying to be > general (SOCK_STREAM) but never really was, whereas we do avoid = some of > that with taps by already starting with more than one underlying= choice > - Wolfgang Beck > - It is interesting that most (all?) IETF docs that talk about > what protocol an app should use never talk about general charate= ristics > like stream/dgram but rather specifically call out TCP or UDP > - Colin > - Quick followup on the ICE point, you may have to hook this > racing into the application state > - Spencer > - Interested in the comments about modern dev cycles vs > historic, and would like this explored more before last call > - Tommy: the tail of people who are not pushing new updates to > their code are probably not going to adopting anything beyond BS= D sockets > anyway > 6. > > draft-fairhurst-taps-neat-00, Gorry Fairhurst, University of Aberdeen > -20 min > - See slides > - Zahed: Who is setting up the policy? > - Gorry: Internal interface in neat, from the policy manager > - Personally pefer binary keywords for desired characteristics, > like "low latency", over specific metrics > - Slight concerns about making things overly complicated into the > neat api > - Strongly believe taps API has to be callback based to support the > expected mechanisms of the current app dev world > - Aaron > - Can you say anything about the example apps? > - Gorry: well we can send bytes backwards and forwards, so > that's good right? And Mozilla has something working with it > - Mirja > - The base architecture should be a message not a stream > - Gorry: totally agree with you > - Still some fuzziness around transport/session layer > - Kyle > - Minor quibble on making it event driven, because sometimes you > don't really want to use that style (maybe using imperative/bloc= king, maybe > using CPS) > - What you want is the API to express various programming > models, maybe with the event-based model as the foundation for o= thers if > it's sufficiently expressive to capture all widely-used models > - Gorry: system is based on libuv, and yes maybe we could do > other models on top of that as the substrate > - Tommy > - We definitely don't want blocking to be the main API but there > are multiple models for asynchronousity > - Abstract API should absolutely not have anything specific > about how to implement it, just the features needed > - Wolfgang Beck > - ? ... sorry missed that first comment (so did I) > - Issues about limiting th queue size is not that useful without > understanding other issues w.r.t rate / etc. What we really want= is more > like the Van Jacobsen model with something like packet soldiers(= ?) > - Gorry: you're a realtime person, aren't you? > - Yes so coming from that perspective > - Zahed > - Gorry: See happy eyeballs as "how do you decide on a final > transport?" But then you have the problem of choosing the candid= ates, and > that's the bit where the policy engine(?) fits in. > - Gorry > - Deciding on an architecture will help a lot with nailing down > terminology > 7. > > Discussion on charter item 3 - 10 min > - Aaron > - Look at the history of the group, and how the possibility of > rechartering was considered early on based on initial results > - Aaron's feelig the love > - Let the record show: Aaron is happy. > - My gut tells me that there is a useful common architecture can > be extracted from this. What does the group think? > - Brian Trammel > - We basically do have some architectures, so can be chosing to > continue that as wg business. Like postsockets is an architectur= e > - Aaron: I would be pleased to hear whether the people who work > on other projects (neat) would be good with working with that > - Mirja > - The different projects have different levels of abstraction, > so we should be deciding on what level of abstraction to use > - Should pursue as unified, not two separate abstraction layers > - Michael > - Essential agreement with Mirja > - Aaron: implementation experience is extremely valuable for > validating these ideas > - Gorry > - Not incompatible; just different levels > - Anna > - Neat is not abstract enough but postsockets probably too > abstract, would be good to find something in the middle > - Tommy > - We have enough experience in the room with various > implementations. Agree this is at a very abstract level. There's= a neat > implementation doc saying "this is how we decided to implement i= t". I could > produce one of those also for how we (Apple) implemented it. > - What I want to see out of postsockets is something that is > forward looking enough to still be relevant in 10 years but stil= l > implementable now > - --over time-- > - Mirja > - Phillip > - Good to see that postsockets/neat is moving toward a common > language and want to keep them separate for now to see how they = might > naturally come together over time > - Tommy > - One thing that could help speed up that coming together is a > terminoogy document to solidify that common language (eg, to def= ine what a > path is, etc) > - Aaron thinks the bar is low for defining terminology. Aaron is > apparently new to the IETF > > --fin > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a11404b84160b0e05615597ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IIRC the person marked as ? in the draft-tiesel-taps-socketintents-01 slot was Nacho Solis.=C2=A0

Best,
Chris

On Thu, Dec 21, 2017 at 10:10 AM Aaron Falk &l= t;aaron.falk@gmail.com> wrot= e:

We=E2=80=99re overdue for filing the minutes from our Singa= pore meeting. Please give the (very good) notes by Kyle & Tale a look = and send comments.

=E2=80=94aaron

TAPS
IETF-100 Singapore
Tuesday, November 14, 2017
Room: Olivia

Minute takers:
Kyle Rose
tale

  1. Chairs update - 10 min

    • Charter bashng
      • Chris, Aaron, Kyle agreed we need more precise charter language for the= WG's transport security function.

  2. draft-ietf-taps-minset-00 - Michael Wizel, = University of Oslo -15 min

    • Brian Trammell
      • Is this an API certification? <laugh>
      • There's an implicit assumption of ordering in protocols based on nu= mber of features
      • From standpoint of feature set that you need to meet, that's the ri= ght way to think about it
      • Thinks doc is close to done
    • Tommy Pauly
      • Need to explicitly declare required features for a transport up-front
      • Remove all references to "fallback" because it implies a part= icular set of preferences/priorities that imply a total order
      • Instead, just catalog protocols by features provided and leave ordering= to another doc
    • Spencer Dawkins (responsible AD)
      • Agrees with Tommy
    • Completeness
      • Aaron: What is required for document to be complete?
      • Michael: Tommy to proofread
      • Gabriel: Is CoAP supported?
      • Michael: Minset analysis based on a survey of important existing transp= ort protocols
      • Aaron: Goal of minset is to identify minimum set of functions that a TA= PS API should support to cover the basic set of functionality required by I= ETF protocols. If there's something missing from CoAP, maybe there'= s stuff in minset that shouldn't be there; alternatively, it may be tha= t CoAP is not expressive enough to be usable through the TAPS API
      • Bob Moskovitz: Purpose of TAPS should be to disconnect the application = from the details of the transport, whether or not a constrained transport &= lt;---this probably needs clarification
      • Tommy: (missed)
      • Mirja: How to map this to post-sockets? Anything that isn't related= to connection establishment or data transfer should be separated out
      • Michael: "Maintenance" covers the configuration aspects of pr= otocols
      • Tommy: Pieces of functionality that are core transport functionality, a= nd then protocol-specific (or model-specific) things that need to be separa= ted out
      • Michael: Need to distinguish between what needs to be said up-front, bu= t I don't like the idea of separating out core functionality from non-c= ore
      • Mirja: There is a box called "configuration" in post-sockets.= We need to know what goes in there.
      • Brian: There are things you need to do during connection setup that can= 't be changed without tearing down connection state: not maintenance. I= s this an API specification? It's a specification for APIs that impleme= nt TAPS. Would be useful if the knobs available here were organized in a be= tter way. May just need to add another layer to express additional configur= ation.

  3. draft-trammell-taps-post-sockets-03, Brian = Trammell, ETH Zurich - 20 min

    • Brian Trammel
      • Hard requirement that the protocol stack configuration work without a r= equirement that a bunch of config be provided.
      • "Configuration" box is what you use to constrain the magic pr= otocol configuration state maintained for a path in the association.
      • Obviate the need for dicking around with sockopts because the defaults = are saner.
    • Tommy Pauly
      • IF you use TCP, set this option; IF you choose SCTP, = do this. Extra knobs if you need something very specific.
      • Noted another change in the draft is around messages; we like the messa= ge abstraction but need to understand how that relates to streams and chunk= ing
    • Praveen from Microsoft
      • How do you reconcile system configuration with app configuration(? not = sure I got that right)
      • Brian: the jokey answers is that it sort of looks like cascading style = sheets, using predictable overrides to get a final instance configuration. = hope to do better than CSS
    • Kyle Rose
      • Re predictability and "too much magic" making things hard to = figure out with regard to performance targets etc
        • Brian: Yes really, let's talk about this offline because it'll = be like a half hour discussion
      • Accessability of specific aspects of different transport protocol featu= res (maybe non-obvious requirements, like degrading perf on purpose for tes= ting purposes)
        • Brian: the intention is to make it all available through the API if you= know which one you're working with
    • Brian
      • Open issues:=20
        • a protocol-independent carrier state machine
        • how to represent certain transport-specific interactions
      • Bring this into the wg now?
        • critical mass of Abstract interface proposals now
        • ready to take the creative leap to design the API
        • Aaron: actually this does sound like a charter change for architecture=
        • name?: In a way this is looking at "maxset" rather than "= ;minset"
        • Michael Wetzl: the reason the charter is so conservative was because pe= ople couldn't really agree so had to be pared down. Agree that it is g= ood to have a higher layer, but concerned about the implementability
        • Aaron: moving into the territory of a charter revision, which we're= not going to talk about right now. mic closed.

  4. draft-tiesel-taps-socketintents-01, Philipp= S. Tiesel, TU Berlin - 20 min

    • Automated Transport Option Selection (see slides)
    • Desire to use same set of (essential) keywords no matter what programmi= ng language is being used
    • Main questions: is this easy enough and useful enough to devs? suffici= ent to express the usual set of intents? what's missing?
    • Michael Wetzl:
      • could be missing out some things that might not be obvious from looking= at current protocols
    • ?:=20
      • How to app dev really know how to understand things like the implicatio= ns of burstiness? or what bitrates it is using?
      • Philip: An app should have a fairly intuitive understanding of whether = it is constant or bursty, even if it doesn't know the specifics of volu= me
    • Praveen:
      • Think it really needs some way of indicating the pattern of traffic (eg= , send/receive messages)
      • Philip: +1
    • Tommy:
      • Very difficult area to get right; we're going to need to expose the= protocol knobs
      • Definitely want to see this discussion happening in the WG even if this= particular set of options is torn down. Expect it to be a tricky, difficu= lt discussion
    • Aaron Falk:
      • Have you implemented it?
      • Philip: limited implementation on top of BSD Sockets
      • This does go back to the ATM classification discussions and previous at= tempts to categorize what is expected of the network
      • This table is an "attractive nuisance" for criticism and a go= od starting point
      • Philip: agreed, it is just a starting point and not being proposed as t= he end point
    • ?
      • The table worries me because it seems far to easy to rathole on each el= ement of it
      • Aaron: are there semantics from the ABT world that would be useful?
    • ?
      • An issue in the table that "intents" are about things the app= is signalling what it intends to do, but other things there are not really= intents but something the app desires
      • It isn't useful for apps to just only be able to say "give me = all the best performance always" but rather to have to indicate what t= he trade-offs are
    • Mirja Kuhlewind:
      • Agree with ?previous speaker. Not really sure what does make sense to = specify here.
    • Brian:
      • "Can you go back to the ATM table [slide] again?"
      • Two main issues with this; the further right you get the happier I am a= nd to the left the sadder. It's sort of like a heat map of how I like = the table.
      • Table helped clarify for me the separations that are needed
      • Two distincts groups of people in this room, apps chauvanists and trans= port chauvinists, and these are in tension for designing the architecture. = really need to find the balance.
      • This way is application chauvanist (and I'm [Brian] also applicatio= n chauvanist) but we need to call that out
    • David Schinazi
      • Another type of chauvanist, an engineering chauvanist, which I am
      • Definitely value in some sort of registry for different types of intent= s and showing how they could be used
      • Premature to have a laundry list of all the things we might possibly wa= nt without an understanding of how we really want to use them (like burstin= ess)
    • Gorry Fairhurst:
      • I like the list; I think the list should be bigger, but the datatype va= lues should mostly be binary (enums)
    • Philip:
      • Open question: is this the way the IETF describes Abstract APIs?

  5. draft-pauly-taps-guidelines-01 - Tommy Paul= y, Apple -25 min

    • See slides, on the topic of racing connections
    • Tommy ... didn't even get off the title slide before Colin was @ th= e mic
    • Colin
      • Scoping question: when you say racing do you mean Happy Eyeballs or thi= ngs like ICE as well?
      • Tommy: mostly from Happy Eyeballs perspective
    • Aaron:
      • Is split VPN definining separate peths?
      • Tommy: conceptually yes
    • Colin
      • Trying to still figure out the difference between a path and endpoints<= /li>
      • ICE is about determing what works
      • Tommy: which yes is also what this about, and we do need more work w/IC= E
    • Brian
      • (on Avoiding Ossification slide) these things seem to be mutually exclu= sive but maybe not intrinstically so but rather in your approach. not sure= how to fix it though.
      • Tommy: in the context of the current app dev cycle, taps is way better= than BSD sockets api used to be, way easier to just turn on a bit than cha= nge the whole model
      • Re what should be raced or not raced, advantages to doing it tree orien= ted rather than sequence oriented
    • Colin
      • On the ossification point, in the past we were trying to be general (SO= CK_STREAM) but never really was, whereas we do avoid some of that with taps= by already starting with more than one underlying choice
    • Wolfgang Beck
      • It is interesting that most (all?) IETF docs that talk about what proto= col an app should use never talk about general charateristics like stream/d= gram but rather specifically call out TCP or UDP
    • Colin
      • Quick followup on the ICE point, you may have to hook this racing into = the application state
    • Spencer
      • Interested in the comments about modern dev cycles vs historic, and wou= ld like this explored more before last call
      • Tommy: the tail of people who are not pushing new updates to their code= are probably not going to adopting anything beyond BSD sockets anyway

  6. draft-fairhurst-taps-neat-00, Gorry Fairhur= st, University of Aberdeen -20 min

    • See slides
    • Zahed: Who is setting up the policy?
    • Gorry: Internal interface in neat, from the policy manager
    • Personally pefer binary keywords for desired characteristics, like &quo= t;low latency", over specific metrics
    • Slight concerns about making things overly complicated into the neat ap= i
    • Strongly believe taps API has to be callback based to support the expec= ted mechanisms of the current app dev world
    • Aaron
      • Can you say anything about the example apps?
      • Gorry: well we can send bytes backwards and forwards, so that's go= od right? And Mozilla has something working with it
    • Mirja
      • The base architecture should be a message not a stream
      • Gorry: totally agree with you
      • Still some fuzziness around transport/session layer
    • Kyle
      • Minor quibble on making it event driven, because sometimes you don'= t really want to use that style (maybe using imperative/blocking, maybe usi= ng CPS)
      • What you want is the API to express various programming models, maybe w= ith the event-based model as the foundation for others if it's sufficie= ntly expressive to capture all widely-used models
      • Gorry: system is based on libuv, and yes maybe we could do other models= on top of that as the substrate
    • Tommy
      • We definitely don't want blocking to be the main API but there are = multiple models for asynchronousity
      • Abstract API should absolutely not have anything specific about how to = implement it, just the features needed
    • Wolfgang Beck
      • ? ... sorry missed that first comment (so did I)
      • Issues about limiting th queue size is not that useful without understa= nding other issues w.r.t rate / etc. What we really want is more like the = Van Jacobsen model with something like packet soldiers(?)
      • Gorry: you're a realtime person, aren't you?
      • Yes so coming from that perspective
    • Zahed
      • Gorry: See happy eyeballs as "how do you decide on a final transpo= rt?" But then you have the problem of choosing the candidates, and tha= t's the bit where the policy engine(?) fits in.
    • Gorry
      • Deciding on an architecture will help a lot with nailing down terminolo= gy

  7. Discussion on charter item 3 - 10 min

    • Aaron
      • Look at the history of the group, and how the possibility of recharteri= ng was considered early on based on initial results
      • Aaron's feelig the love
      • Let the record show: Aaron is happy.
      • My gut tells me that there is a useful common architecture can be extra= cted from this. What does the group think?
    • Brian Trammel
      • We basically do have some architectures, so can be chosing to continue = that as wg business. Like postsockets is an architecture
      • Aaron: I would be pleased to hear whether the people who work on other = projects (neat) would be good with working with that
    • Mirja
      • The different projects have different levels of abstraction, so we shou= ld be deciding on what level of abstraction to use
      • Should pursue as unified, not two separate abstraction layers
    • Michael
      • Essential agreement with Mirja
      • Aaron: implementation experience is extremely valuable for validating t= hese ideas
    • Gorry
      • Not incompatible; just different levels
    • Anna
      • Neat is not abstract enough but postsockets probably too abstract, woul= d be good to find something in the middle
    • Tommy
      • We have enough experience in the room with various implementations. Agr= ee this is at a very abstract level. There's a neat implementation doc = saying "this is how we decided to implement it". I could produce = one of those also for how we (Apple) implemented it.
      • What I want to see out of postsockets is something that is forward look= ing enough to still be relevant in 10 years but still implementable now
    • --over time--
    • Mirja
    • Phillip
      • Good to see that postsockets/neat is moving toward a common language an= d want to keep them separate for now to see how they might naturally come t= ogether over time
    • Tommy
      • One thing that could help speed up that coming together is a terminoogy= document to solidify that common language (eg, to define what a path is, e= tc)
    • Aaron thinks the bar is low for defining terminology. Aaron is apparen= tly new to the IETF

--fin

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--001a11404b84160b0e05615597ad-- From nobody Wed Dec 27 20:59:19 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E46126DC2 for ; Wed, 27 Dec 2017 20:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx6orxZIrrcM for ; Wed, 27 Dec 2017 20:59:15 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF491241FC for ; Wed, 27 Dec 2017 20:59:15 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id y78so38514349lfd.1 for ; Wed, 27 Dec 2017 20:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=gtqPgBr2dtTSZSqCq6+JZ8x5fBxyB7NWjKTRD5229Uw=; b=B4di6xS02XPMBEivSK1RgMht/uKc5lug/hOWgPxy2hktCqUXu170bcduZVgiGq0FwY YBCbA1U01sJmU0GAl4K6RQYru2BaQy4EsqLDJ2pKq8FJ0AWiVCVwbQw8w2XMUl8+RNls qg6MQUb4Hnk6heMPUvRpXbfpmvlSdoFigADG9SiMr8eBBGWqzrCM6G96Nv6OT3721xD7 4cqnrj9E8R3kYbnmz0rAZYWJPcxyUmaPb+icUJowO5nK/xFxFzaRfoyeMAJ1x4qeEl8I PE95pBUnbD3MV3mCOEFeGlpPEdAVD9QbLqprwKcI9MgB6w77u6FQSHRzy4uaHJ1Illl/ TahQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=gtqPgBr2dtTSZSqCq6+JZ8x5fBxyB7NWjKTRD5229Uw=; b=eivmZO58CmPk98TQsND7AOjOg/l49CDtzw8TUEDrSBMkXBykFy6ec67eRRaRRF80Ms m6AXFAzAtnQHgZBOFCDOHdjpT8kLC7QhJ6/DrV8EwlsECp0e9nsEotL69/g6Qdz7003J linqtLtTlQaRSL9980lOeFCN7iF+zWzemK5c8M6ZyFVbDUE66wJ0tuL0I+/UeLIAxgia r5jFajZObBNm2NLP/QQAyQXmF87HGbRqHZ+9u5rt+EDwwxSXV+8FV5VrHXMxZ+QfEKom WT2Jby6w6dwH4quTB0kV+275X+FKCbNfREkb/GA+H4qOsh6KZuh978q0FLZ6nNpuWRcq WkHg== X-Gm-Message-State: AKGB3mJTXXXcbJn+4WE2vbXe71g2wMleASLIeKNpzCbWmhgXb9tRlurs NRZobu9BCDr+nwrw+OGOCZYbD8SouiCVznJHLSo= X-Google-Smtp-Source: ACJfBos6zUCMHeZ3WYGQbMglO2x8WyDA92FJUZV51BcaAdpddVIGCf7WS4LrjK0tKBmqc+qAJT6CBxjhHw7sc2ePvEY= X-Received: by 10.46.85.134 with SMTP id g6mr18247221lje.84.1514437152875; Wed, 27 Dec 2017 20:59:12 -0800 (PST) MIME-Version: 1.0 Sender: ignacio.solis@gmail.com Received: by 10.46.17.136 with HTTP; Wed, 27 Dec 2017 20:59:11 -0800 (PST) In-Reply-To: References: From: Ignacio Solis Date: Wed, 27 Dec 2017 20:59:11 -0800 X-Google-Sender-Auth: xG240vLQFGOqz5qii-E3JYZuYsE Message-ID: To: Christopher Wood Cc: Aaron Falk , taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Draft TAPS minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 04:59:18 -0000 I'm amazed somebody (other than the chairs) actually goes through and reads the minutes. I do remember saying something, but I'm hoping it was more eloquent at the time. (external observers might have classified it as "rat holing"). I may be a couple of the "?"s. I believe I was trying to say that not all applications will know what is their "intent" with respect to the network. Also, each intent type will have to be carefully constructed to be useful and not to create confusion (think of bursty at different time scales). Also (do we want to get into this?) how will meta/super protocols behave? (think of QUIC). Like I mentioned at some point, I would rather focus on trade-offs (ordering?) so the system can make choices for me. And finally, we should consider giving some guidance of when you should just "use another `socket`" (probably analogous to "use another thread"). Nacho On Wed, Dec 27, 2017 at 9:18 AM, Christopher Wood wrote: > IIRC the person marked as ? in the draft-tiesel-taps-socketintents-01 slo= t > was Nacho Solis. > > Best, > Chris > > On Thu, Dec 21, 2017 at 10:10 AM Aaron Falk wrote: >> >> We=E2=80=99re overdue for filing the minutes from our Singapore meeting.= Please >> give the (very good) notes by Kyle & Tale a look and send comments. >> >> =E2=80=94aaron >> >> ________________________________ >> >> TAPS >> IETF-100 Singapore >> Tuesday, November 14, 2017 >> Room: Olivia >> >> Minute takers: >> Kyle Rose >> tale >> >> Chairs update - 10 min >> >> Charter bashng >> >> Chris, Aaron, Kyle agreed we need more precise charter language for the >> WG's transport security function. >> >> draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min >> >> Brian Trammell >> >> Is this an API certification? >> There's an implicit assumption of ordering in protocols based on number = of >> features >> From standpoint of feature set that you need to meet, that's the right w= ay >> to think about it >> Thinks doc is close to done >> >> Tommy Pauly >> >> Need to explicitly declare required features for a transport up-front >> Remove all references to "fallback" because it implies a particular set = of >> preferences/priorities that imply a total order >> Instead, just catalog protocols by features provided and leave ordering = to >> another doc >> >> Spencer Dawkins (responsible AD) >> >> Agrees with Tommy >> >> Completeness >> >> Aaron: What is required for document to be complete? >> Michael: Tommy to proofread >> Gabriel: Is CoAP supported? >> Michael: Minset analysis based on a survey of important existing transpo= rt >> protocols >> Aaron: Goal of minset is to identify minimum set of functions that a TAP= S >> API should support to cover the basic set of functionality required by I= ETF >> protocols. If there's something missing from CoAP, maybe there's stuff i= n >> minset that shouldn't be there; alternatively, it may be that CoAP is no= t >> expressive enough to be usable through the TAPS API >> Bob Moskovitz: Purpose of TAPS should be to disconnect the application >> from the details of the transport, whether or not a constrained transpor= t >> <---this probably needs clarification >> Tommy: (missed) >> Mirja: How to map this to post-sockets? Anything that isn't related to >> connection establishment or data transfer should be separated out >> Michael: "Maintenance" covers the configuration aspects of protocols >> Tommy: Pieces of functionality that are core transport functionality, an= d >> then protocol-specific (or model-specific) things that need to be separa= ted >> out >> Michael: Need to distinguish between what needs to be said up-front, but= I >> don't like the idea of separating out core functionality from non-core >> Mirja: There is a box called "configuration" in post-sockets. We need to >> know what goes in there. >> Brian: There are things you need to do during connection setup that can'= t >> be changed without tearing down connection state: not maintenance. Is th= is >> an API specification? It's a specification for APIs that implement TAPS. >> Would be useful if the knobs available here were organized in a better w= ay. >> May just need to add another layer to express additional configuration. >> >> draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 min >> >> Brian Trammel >> >> Hard requirement that the protocol stack configuration work without a >> requirement that a bunch of config be provided. >> "Configuration" box is what you use to constrain the magic protocol >> configuration state maintained for a path in the association. >> Obviate the need for dicking around with sockopts because the defaults a= re >> saner. >> >> Tommy Pauly >> >> IF you use TCP, set this option; IF you choose SCTP, do this. Extra knob= s >> if you need something very specific. >> Noted another change in the draft is around messages; we like the messag= e >> abstraction but need to understand how that relates to streams and chunk= ing >> >> Praveen from Microsoft >> >> How do you reconcile system configuration with app configuration(? not >> sure I got that right) >> Brian: the jokey answers is that it sort of looks like cascading style >> sheets, using predictable overrides to get a final instance configuratio= n. >> hope to do better than CSS >> >> Kyle Rose >> >> Re predictability and "too much magic" making things hard to figure out >> with regard to performance targets etc >> >> Brian: Yes really, let's talk about this offline because it'll be like a >> half hour discussion >> >> Accessability of specific aspects of different transport protocol featur= es >> (maybe non-obvious requirements, like degrading perf on purpose for test= ing >> purposes) >> >> Brian: the intention is to make it all available through the API if you >> know which one you're working with >> >> Brian >> >> Open issues: >> >> a protocol-independent carrier state machine >> how to represent certain transport-specific interactions >> >> Bring this into the wg now? >> >> critical mass of Abstract interface proposals now >> ready to take the creative leap to design the API >> Aaron: actually this does sound like a charter change for architecture >> name?: In a way this is looking at "maxset" rather than "minset" >> Michael Wetzl: the reason the charter is so conservative was because >> people couldn't really agree so had to be pared down. Agree that it is g= ood >> to have a higher layer, but concerned about the implementability >> Aaron: moving into the territory of a charter revision, which we're not >> going to talk about right now. mic closed. >> >> draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 mi= n >> >> Automated Transport Option Selection (see slides) >> Desire to use same set of (essential) keywords no matter what programmin= g >> language is being used >> Main questions: is this easy enough and useful enough to devs? sufficien= t >> to express the usual set of intents? what's missing? >> Michael Wetzl: >> >> could be missing out some things that might not be obvious from looking = at >> current protocols >> >> ?: >> >> How to app dev really know how to understand things like the implication= s >> of burstiness? or what bitrates it is using? >> Philip: An app should have a fairly intuitive understanding of whether i= t >> is constant or bursty, even if it doesn't know the specifics of volume >> >> Praveen: >> >> Think it really needs some way of indicating the pattern of traffic (eg, >> send/receive messages) >> Philip: +1 >> >> Tommy: >> >> Very difficult area to get right; we're going to need to expose the >> protocol knobs >> Definitely want to see this discussion happening in the WG even if this >> particular set of options is torn down. Expect it to be a tricky, diffic= ult >> discussion >> >> Aaron Falk: >> >> Have you implemented it? >> Philip: limited implementation on top of BSD Sockets >> This does go back to the ATM classification discussions and previous >> attempts to categorize what is expected of the network >> This table is an "attractive nuisance" for criticism and a good starting >> point >> Philip: agreed, it is just a starting point and not being proposed as th= e >> end point >> >> ? >> >> The table worries me because it seems far to easy to rathole on each >> element of it >> Aaron: are there semantics from the ABT world that would be useful? >> >> ? >> >> An issue in the table that "intents" are about things the app is >> signalling what it intends to do, but other things there are not really >> intents but something the app desires >> It isn't useful for apps to just only be able to say "give me all the be= st >> performance always" but rather to have to indicate what the trade-offs a= re >> >> Mirja Kuhlewind: >> >> Agree with ?previous speaker. Not really sure what does make sense to >> specify here. >> >> Brian: >> >> "Can you go back to the ATM table [slide] again?" >> Two main issues with this; the further right you get the happier I am an= d >> to the left the sadder. It's sort of like a heat map of how I like the >> table. >> Table helped clarify for me the separations that are needed >> Two distincts groups of people in this room, apps chauvanists and >> transport chauvinists, and these are in tension for designing the >> architecture. really need to find the balance. >> This way is application chauvanist (and I'm [Brian] also application >> chauvanist) but we need to call that out >> >> David Schinazi >> >> Another type of chauvanist, an engineering chauvanist, which I am >> Definitely value in some sort of registry for different types of intents >> and showing how they could be used >> Premature to have a laundry list of all the things we might possibly wan= t >> without an understanding of how we really want to use them (like burstin= ess) >> >> Gorry Fairhurst: >> >> I like the list; I think the list should be bigger, but the datatype >> values should mostly be binary (enums) >> >> Philip: >> >> Open question: is this the way the IETF describes Abstract APIs? >> >> draft-pauly-taps-guidelines-01 - Tommy Pauly, Apple -25 min >> >> See slides, on the topic of racing connections >> Tommy ... didn't even get off the title slide before Colin was @ the mic >> Colin >> >> Scoping question: when you say racing do you mean Happy Eyeballs or thin= gs >> like ICE as well? >> Tommy: mostly from Happy Eyeballs perspective >> >> Aaron: >> >> Is split VPN definining separate peths? >> Tommy: conceptually yes >> >> Colin >> >> Trying to still figure out the difference between a path and endpoints >> ICE is about determing what works >> Tommy: which yes is also what this about, and we do need more work w/ICE >> >> Brian >> >> (on Avoiding Ossification slide) these things seem to be mutually >> exclusive but maybe not intrinstically so but rather in your approach. n= ot >> sure how to fix it though. >> Tommy: in the context of the current app dev cycle, taps is way better >> than BSD sockets api used to be, way easier to just turn on a bit than >> change the whole model >> Re what should be raced or not raced, advantages to doing it tree orient= ed >> rather than sequence oriented >> >> Colin >> >> On the ossification point, in the past we were trying to be general >> (SOCK_STREAM) but never really was, whereas we do avoid some of that wit= h >> taps by already starting with more than one underlying choice >> >> Wolfgang Beck >> >> It is interesting that most (all?) IETF docs that talk about what protoc= ol >> an app should use never talk about general charateristics like stream/dg= ram >> but rather specifically call out TCP or UDP >> >> Colin >> >> Quick followup on the ICE point, you may have to hook this racing into t= he >> application state >> >> Spencer >> >> Interested in the comments about modern dev cycles vs historic, and woul= d >> like this explored more before last call >> Tommy: the tail of people who are not pushing new updates to their code >> are probably not going to adopting anything beyond BSD sockets anyway >> >> draft-fairhurst-taps-neat-00, Gorry Fairhurst, University of Aberdeen -2= 0 >> min >> >> See slides >> Zahed: Who is setting up the policy? >> Gorry: Internal interface in neat, from the policy manager >> Personally pefer binary keywords for desired characteristics, like "low >> latency", over specific metrics >> Slight concerns about making things overly complicated into the neat api >> Strongly believe taps API has to be callback based to support the expect= ed >> mechanisms of the current app dev world >> Aaron >> >> Can you say anything about the example apps? >> Gorry: well we can send bytes backwards and forwards, so that's good >> right? And Mozilla has something working with it >> >> Mirja >> >> The base architecture should be a message not a stream >> Gorry: totally agree with you >> Still some fuzziness around transport/session layer >> >> Kyle >> >> Minor quibble on making it event driven, because sometimes you don't >> really want to use that style (maybe using imperative/blocking, maybe us= ing >> CPS) >> What you want is the API to express various programming models, maybe wi= th >> the event-based model as the foundation for others if it's sufficiently >> expressive to capture all widely-used models >> Gorry: system is based on libuv, and yes maybe we could do other models = on >> top of that as the substrate >> >> Tommy >> >> We definitely don't want blocking to be the main API but there are >> multiple models for asynchronousity >> Abstract API should absolutely not have anything specific about how to >> implement it, just the features needed >> >> Wolfgang Beck >> >> ? ... sorry missed that first comment (so did I) >> Issues about limiting th queue size is not that useful without >> understanding other issues w.r.t rate / etc. What we really want is more >> like the Van Jacobsen model with something like packet soldiers(?) >> Gorry: you're a realtime person, aren't you? >> Yes so coming from that perspective >> >> Zahed >> >> Gorry: See happy eyeballs as "how do you decide on a final transport?" B= ut >> then you have the problem of choosing the candidates, and that's the bit >> where the policy engine(?) fits in. >> >> Gorry >> >> Deciding on an architecture will help a lot with nailing down terminolog= y >> >> Discussion on charter item 3 - 10 min >> >> Aaron >> >> Look at the history of the group, and how the possibility of recharterin= g >> was considered early on based on initial results >> Aaron's feelig the love >> Let the record show: Aaron is happy. >> My gut tells me that there is a useful common architecture can be >> extracted from this. What does the group think? >> >> Brian Trammel >> >> We basically do have some architectures, so can be chosing to continue >> that as wg business. Like postsockets is an architecture >> Aaron: I would be pleased to hear whether the people who work on other >> projects (neat) would be good with working with that >> >> Mirja >> >> The different projects have different levels of abstraction, so we shoul= d >> be deciding on what level of abstraction to use >> Should pursue as unified, not two separate abstraction layers >> >> Michael >> >> Essential agreement with Mirja >> Aaron: implementation experience is extremely valuable for validating >> these ideas >> >> Gorry >> >> Not incompatible; just different levels >> >> Anna >> >> Neat is not abstract enough but postsockets probably too abstract, would >> be good to find something in the middle >> >> Tommy >> >> We have enough experience in the room with various implementations. Agre= e >> this is at a very abstract level. There's a neat implementation doc sayi= ng >> "this is how we decided to implement it". I could produce one of those a= lso >> for how we (Apple) implemented it. >> What I want to see out of postsockets is something that is forward looki= ng >> enough to still be relevant in 10 years but still implementable now >> >> --over time-- >> Mirja >> Phillip >> >> Good to see that postsockets/neat is moving toward a common language and >> want to keep them separate for now to see how they might naturally come >> together over time >> >> Tommy >> >> One thing that could help speed up that coming together is a terminoogy >> document to solidify that common language (eg, to define what a path is, >> etc) >> >> Aaron thinks the bar is low for defining terminology. Aaron is apparentl= y >> new to the IETF >> >> --fin >> >> _______________________________________________ >> 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 > --=20 Nacho - Ignacio Solis - isolis@igso.net From nobody Thu Dec 28 03:31:04 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD1127863 for ; Thu, 28 Dec 2017 03:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-9WzI-JRSWp for ; Thu, 28 Dec 2017 03:30:59 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAF31277BB for ; Thu, 28 Dec 2017 03:30:59 -0800 (PST) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eUWOm-000Dlx-Ns; Thu, 28 Dec 2017 12:30:56 +0100 Received: from [185.81.136.30] (helo=[192.168.1.171]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eUWOk-0007AU-FB; Thu, 28 Dec 2017 12:30:56 +0100 From: Michael Welzl Message-Id: <41B33629-3F64-4612-BDD8-AD480A34E9AE@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E37F625-1133-46B3-AA2E-99D100393E63" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 28 Dec 2017 12:30:52 +0100 In-Reply-To: Cc: "taps@ietf.org" To: Aaron Falk References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 185.81.136.30 is neither permitted nor denied by domain of ifi.uio.no) client-ip=185.81.136.30; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.171]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 38F4C3BA44F620399D6A21487ADE33638C7A9F0D Archived-At: Subject: Re: [Taps] Draft TAPS minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 11:31:03 -0000 --Apple-Mail=_5E37F625-1133-46B3-AA2E-99D100393E63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Two fixes inline: > On Dec 21, 2017, at 7:10 PM, Aaron Falk wrote: >=20 > We=E2=80=99re overdue for filing the minutes from our Singapore = meeting. Please give the (very good) notes by Kyle & Tale a look and = send comments. >=20 > =E2=80=94aaron >=20 > TAPS > IETF-100 Singapore > Tuesday, November 14, 2017 > Room: Olivia >=20 > Minute takers: > Kyle Rose > tale >=20 > Chairs update - 10 min >=20 > Charter bashng > Chris, Aaron, Kyle agreed we need more precise charter language for = the WG's transport security function. > draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min >=20 s/Wizel/Welzl pretty please :-) > Brian Trammell > Is this an API certification? > There's an implicit assumption of ordering in protocols based on = number of features > =46rom standpoint of feature set that you need to meet, that's the = right way to think about it > Thinks doc is close to done > Tommy Pauly > Need to explicitly declare required features for a transport up-front > Remove all references to "fallback" because it implies a particular = set of preferences/priorities that imply a total order > Instead, just catalog protocols by features provided and leave = ordering to another doc > Spencer Dawkins (responsible AD) > Agrees with Tommy > Completeness > Aaron: What is required for document to be complete? > Michael: Tommy to proofread > Gabriel: Is CoAP supported? > Michael: Minset analysis based on a survey of important existing = transport protocols > Aaron: Goal of minset is to identify minimum set of functions that a = TAPS API should support to cover the basic set of functionality required = by IETF protocols. If there's something missing from CoAP, maybe there's = stuff in minset that shouldn't be there; alternatively, it may be that = CoAP is not expressive enough to be usable through the TAPS API > Bob Moskovitz: Purpose of TAPS should be to disconnect the application = from the details of the transport, whether or not a constrained = transport <---this probably needs clarification > Tommy: (missed) > Mirja: How to map this to post-sockets? Anything that isn't related to = connection establishment or data transfer should be separated out > Michael: "Maintenance" covers the configuration aspects of protocols > Tommy: Pieces of functionality that are core transport functionality, = and then protocol-specific (or model-specific) things that need to be = separated out > Michael: Need to distinguish between what needs to be said up-front, = but I don't like the idea of separating out core functionality from = non-core > Mirja: There is a box called "configuration" in post-sockets. We need = to know what goes in there. > Brian: There are things you need to do during connection setup that = can't be changed without tearing down connection state: not maintenance. = Is this an API specification? It's a specification for APIs that = implement TAPS. Would be useful if the knobs available here were = organized in a better way. May just need to add another layer to express = additional configuration. > draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 = min >=20 > Brian Trammel > Hard requirement that the protocol stack configuration work without a = requirement that a bunch of config be provided. > "Configuration" box is what you use to constrain the magic protocol = configuration state maintained for a path in the association. > Obviate the need for dicking around with sockopts because the defaults = are saner. > Tommy Pauly > IF you use TCP, set this option; IF you choose SCTP, do this. Extra = knobs if you need something very specific. > Noted another change in the draft is around messages; we like the = message abstraction but need to understand how that relates to streams = and chunking > Praveen from Microsoft > How do you reconcile system configuration with app configuration(? not = sure I got that right) > Brian: the jokey answers is that it sort of looks like cascading style = sheets, using predictable overrides to get a final instance = configuration. hope to do better than CSS > Kyle Rose > Re predictability and "too much magic" making things hard to figure = out with regard to performance targets etc > Brian: Yes really, let's talk about this offline because it'll be like = a half hour discussion > Accessability of specific aspects of different transport protocol = features (maybe non-obvious requirements, like degrading perf on purpose = for testing purposes) > Brian: the intention is to make it all available through the API if = you know which one you're working with > Brian > Open issues: > a protocol-independent carrier state machine > how to represent certain transport-specific interactions > Bring this into the wg now? > critical mass of Abstract interface proposals now > ready to take the creative leap to design the API > Aaron: actually this does sound like a charter change for architecture > name?: In a way this is looking at "maxset" rather than "minset" > Michael Wetzl: the reason the charter is so conservative was because = people couldn't really agree so had to be pared down. Agree that it is = good to have a higher layer, but concerned about the implementability > Aaron: moving into the territory of a charter revision, which we're = not going to talk about right now. mic closed. > draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 = min >=20 > Automated Transport Option Selection (see slides) > Desire to use same set of (essential) keywords no matter what = programming language is being used > Main questions: is this easy enough and useful enough to devs? = sufficient to express the usual set of intents? what's missing? > Michael Wetzl: > could be missing out some things that might not be obvious from = looking at current protocols s/Wetzl/Welzl pretty please :-) and: my statement here, in this context, sounds as if I said that the = socketintents draft "could be missing out some things =E2=80=A6=E2=80=9D. = I believe I said the opposite: that this could be useful because it = shows us things that we might otherwise miss. Suggested re-phrasing: *** this could show us some things that we might be missing out, as they = might not be obvious from looking at current protocols *** That=E2=80=99s it from my side. Thanks, cheers Michael --Apple-Mail=_5E37F625-1133-46B3-AA2E-99D100393E63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Two = fixes inline:


On Dec 21, 2017, at 7:10 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

We=E2=80= =99re overdue for filing the minutes from our Singapore meeting. Please = give the (very good) notes by Kyle & Tale a look and send = comments.

=E2=80=94aaron

TAPS
IETF-100 Singapore
Tuesday, November 14, 2017
Room: Olivia

Minute takers:
Kyle Rose
tale

  1. Chairs update - 10 = min

    • Charter bashng
      • Chris, Aaron, Kyle agreed we need more precise charter = language for the WG's transport security function.

  2. draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo = -15 = min

s/Wizel/Welzl =  pretty please  :-)


    • Brian Trammell
      • Is this an API certification? <laugh>
      • There's an implicit assumption of ordering in protocols = based on number of features
      • =46rom standpoint of feature set that you need to meet, = that's the right way to think about it
      • Thinks doc is close to done
    • Tommy Pauly
      • Need to explicitly declare required features for a = transport up-front
      • Remove all references to "fallback" because it implies a = particular set of preferences/priorities that imply a total order
      • Instead, just catalog protocols by features provided and = leave ordering to another doc
    • Spencer Dawkins (responsible AD)
      • Agrees with Tommy
    • Completeness
      • Aaron: What is required for document to be complete?
      • Michael: Tommy to proofread
      • Gabriel: Is CoAP supported?
      • Michael: Minset analysis based on a survey of important = existing transport protocols
      • Aaron: Goal of minset is to identify minimum set of = functions that a TAPS API should support to cover the basic set of = functionality required by IETF protocols. If there's something missing = from CoAP, maybe there's stuff in minset that shouldn't be there; = alternatively, it may be that CoAP is not expressive enough to be usable = through the TAPS API
      • Bob Moskovitz: Purpose of TAPS should be to disconnect = the application from the details of the transport, whether or not a = constrained transport <---this probably needs clarification
      • Tommy: (missed)
      • Mirja: How to map this to post-sockets? Anything that = isn't related to connection establishment or data transfer should be = separated out
      • Michael: "Maintenance" covers the configuration aspects = of protocols
      • Tommy: Pieces of functionality that are core transport = functionality, and then protocol-specific (or model-specific) things = that need to be separated out
      • Michael: Need to distinguish between what needs to be = said up-front, but I don't like the idea of separating out core = functionality from non-core
      • Mirja: There is a box called "configuration" in = post-sockets. We need to know what goes in there.
      • Brian: There are things you need to do during connection = setup that can't be changed without tearing down connection state: not = maintenance. Is this an API specification? It's a specification for APIs = that implement TAPS. Would be useful if the knobs available here were = organized in a better way. May just need to add another layer to express = additional configuration.

  2. draft-trammell-taps-post-sockets-03, Brian Trammell, ETH = Zurich - 20 min

    • Brian Trammel
      • Hard requirement that the protocol stack configuration = work without a requirement that a bunch of config be provided.
      • "Configuration" box is what you use to constrain the = magic protocol configuration state maintained for a path in the = association.
      • Obviate the need for dicking around with sockopts because = the defaults are saner.
    • Tommy Pauly
      • IF you use TCP, set this option; IF you choose SCTP, do this. Extra knobs if you need = something very specific.
      • Noted another change in the draft is around messages; we = like the message abstraction but need to understand how that relates to = streams and chunking
    • Praveen from Microsoft
      • How do you reconcile system configuration with app = configuration(? not sure I got that right)
      • Brian: the jokey answers is that it sort of looks like = cascading style sheets, using predictable overrides to get a final = instance configuration. hope to do better than CSS
    • Kyle Rose
      • Re predictability and "too much magic" making things hard = to figure out with regard to performance targets etc
        • Brian: Yes really, let's talk about this offline because = it'll be like a half hour discussion
      • Accessability of specific aspects of different transport = protocol features (maybe non-obvious requirements, like degrading perf = on purpose for testing purposes)
        • Brian: the intention is to make it all available through = the API if you know which one you're working with
    • Brian
      • Open issues:=20
        • a protocol-independent carrier state machine
        • how to represent certain transport-specific = interactions
      • Bring this into the wg now?
        • critical mass of Abstract interface proposals now
        • ready to take the creative leap to design the API
        • Aaron: actually this does sound like a charter change = for architecture
        • name?: In a way this is looking at "maxset" rather than = "minset"
        • Michael Wetzl: the reason the charter is so conservative = was because people couldn't really agree so had to be pared down. Agree = that it is good to have a higher layer, but concerned about the = implementability
        • Aaron: moving into the territory of a charter revision, = which we're not going to talk about right now. mic closed.

  3. draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU = Berlin - 20 min

    • Automated Transport Option Selection (see slides)
    • Desire to use same set of (essential) keywords no matter = what programming language is being used
    • Main questions: is this easy enough and useful enough to = devs? sufficient to express the usual set of intents? what's = missing?
    • Michael Wetzl:
      • could be missing out some things that might not be = obvious from looking at current = protocols
s/Wetzl/Welzl  pretty please  :-)
and: my = statement here, in this context, sounds as if I said that the = socketintents draft "could be missing out some things =E2=80=A6=E2=80=9D. = I believe I said the opposite: that this could be useful because it = shows us things that we might otherwise miss. Suggested = re-phrasing:
***
this could show us some things that = we might be missing out, as they might not be obvious from looking at = current protocols
***

That=E2=80=99= s it from my side. Thanks, cheers
Michael

= --Apple-Mail=_5E37F625-1133-46B3-AA2E-99D100393E63-- From nobody Thu Dec 28 04:08:04 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2FB12D854 for ; Thu, 28 Dec 2017 04:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrV_ItjEt89x for ; Thu, 28 Dec 2017 04:08:00 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410E2126DEE for ; Thu, 28 Dec 2017 04:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vw50fzG+a+ET3tnbpTaXyrjFXlDs/VOw91pd/FYV78w=; b=L1tTqU3J55XPqBVRMpS5PbRTiDHPEupiFrtPz8BgDvwWpt3ivGmiL+VtHwoVMNY8s0uKe5v2iFwhyb1DXqnHLqMjGIc01HXQ51B04FqON3u//2/9AbGnkdTkXcHLPLgg/OHbTDqq3BQAqtXLlshs7t5INmyc+eC4PU1ocWWWHlA= Received: from pc6 (86.169.153.236) by HE1PR07MB1563.eurprd07.prod.outlook.com (2a01:111:e400:7a2d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Thu, 28 Dec 2017 12:07:54 +0000 Message-ID: <000901d37fd3$e50df300$4001a8c0@gateway.2wire.net> From: "tom p." To: "Ignacio Solis" Cc: "Aaron Falk" , "taps WG" References: Date: Thu, 28 Dec 2017 12:03:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: AM4P190CA0008.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::18) To HE1PR07MB1563.eurprd07.prod.outlook.com (2a01:111:e400:7a2d::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a20d32a7-3a80-4e67-abfd-08d54deba0b6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(8989060)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307); SRVR:HE1PR07MB1563; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 3:jZRjQHJqycqUkSWjAqrb9ZJdFsqH8BI+XCQqcgBX1xxYSD+aqt1akjnAecS3XFIP8HL8n+ylhnDNTyVN4yyALCWJ9t044kRg9V0fQID9ZaCjntAWNkRooORUB+pVojZDvk7uNB6t49E+FT6vgbhqO63Xv97ThEitD7eKbQVfCesWWmnZDotnpkx690uku/S3Yp/qncuP2kmPb9fRjZe04a/C/c52t9LB/+GUPXVS6QkJIZEQBvDJhpAXDrePWJMa; 25:sg+WVuBwUBgxav02kKM/cD0bfi23+k/nGnZ+/0Qd/DUAr3ZpLS4sJ+Tw+rL5t4//IbCDKuYKEfkeMk8qN6g+D0d22lmgkiCwz6Gg3dQSKg4ftmyYL7EuIUYuxcXp4BgaLClxVnD5rt5cYxtRqEVIi5frj0GEnMKj6PmgwXUX+NFA7ZglRApfif30mCgWVC7o28NDQsdOcT3hjeoDER3xhDmLhBrWKqvOsApK8uPX+TrEslQM5JLbUuhv6GHOEve6TWbWuO20/o1JBoqEu8EVFx9P5RkOoDr4+GnMd4XM0T2ijmx2sTghDFG01IsMpJzDxAwT9pP+IHalYHXuUSND7+jfmGNTvfL8MWTSG2MYGBA=; 31:TH4RfEU5IEU6h9q+K53jnfzkbpdC2Tmm4FnQoP0huwJ+cL1HRGBFhETozByzul3GiFXLGC8QCRqImCk1KjuDfkvpmND7u+QxCBPTolIuvG5QCCha/YvjJptV7/4Yjx6mfrfFZkf2HWgNjoAE02dsZynHVjUgB1712NDv/BJanr55qOlXe5gXATU8AwCtZ/dtzYSpoywnxht+DIv3mY3Nn+vnpTtwIvIbzZBMM7v6Wy8= X-MS-TrafficTypeDiagnostic: HE1PR07MB1563: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(100405760836317)(5213294742642); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR07MB1563; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB1563; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 4:N19EhdDh+S4t2gt6wQCmD6Nddq2MPko8A7BN5Rvpy6jUSrhsQR1QhrAk0x94OZ/B+ZRS36pZRakHN5wo25/uIfd2+YUiqiUaZrEru/X0TU8Rk94//7RTaar9kWWmNFvawzgnossuLmIb/Rj55yp9YlqfCRsObRwQmGjnx2sxe8iUhJFJbUjiQoCDynf21XDUplK2Y/ocA9tkk47Emq7x0QA78szecnNLZVL4K2RoAGnw9jS0qsE7Zo9uVNsY4Guo4IyfSq/sR12Bd8FGV9MHJU3ZgZZJKhonMmx4tBLDPGlfF/Ht4Gt/rsWpfWcsKzYzIGpQICoVX7s1dOIFtx41NnhNTp+J3mMS0yVLdEldtUBNK7jw8ps8UzsasmPNxkhlNlTTaTOqwpkUAH0wXVM5k6jq+/ojuhKsAFS0q2tTb0E= X-Forefront-PRVS: 05352A48BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(366004)(39860400002)(39380400002)(51444003)(24454002)(13464003)(189003)(199004)(1456003)(97736004)(16526018)(305945005)(7736002)(59450400001)(8936002)(6496006)(50466002)(105586002)(106356001)(2870700001)(386003)(53546011)(62236002)(6246003)(44716002)(4326008)(81816011)(66066001)(61296003)(52116002)(23676004)(76176011)(33896004)(44736005)(2906002)(47776003)(6306002)(9686003)(5660300001)(50226002)(84392002)(25786009)(2486003)(53936002)(6116002)(6666003)(81686011)(6486002)(4720700003)(6916009)(81156014)(81166006)(229853002)(54906003)(3846002)(39060400002)(8676002)(68736007)(86362001)(14496001)(1556002)(116806002)(45080400002)(478600001)(966005)(316002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1563; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNTYzOzIzOlQrb0hGdFdRbU83a01IT05LVTlVZXIxcHhV?= =?utf-8?B?MWwvSm9YWWsycC90ckIrdDNZZmNyVDRPSU8wcU9IUHpld3ZjRWFvR3B5VU1R?= =?utf-8?B?UXllbjNSU2RESzZjdUpnclBTOG1sZDU2TW8yNER0L3JtZFJINHhJNWlCOHdR?= =?utf-8?B?bjQwMzdITHZJTkpDZndYMENpK3ZsaDMvZHVIR2ZnR1lkdmN1cVJxNHdpSkgy?= =?utf-8?B?NzNGeC9KM2lxWVlHWE9IUXN5ZFBCc1hzbTU2RHZGWXFNR2g1WWdnTytIcC9z?= =?utf-8?B?cURWL2NYcnBCVWpibUR4WENVZExKREFBWEl2UllDdTVDdy9OSFFlcG54N1pk?= =?utf-8?B?d0FaRzNyN1E3MlU0T1oxMUd1OTZKV2d1ZWJ2T3YrMnVFN2phVnFHdk1RYmVK?= =?utf-8?B?ZENkWVlhWDVXK2tJUDdQUHMzcGFMU1dCSE0ya1krcGlremZ3L1lYYjZkZEll?= =?utf-8?B?Z3JyZDdKTm5EVDdnODNrYWNoelpJQ3lGbXdXMDl4RkNTVUtnOEluOG9lU3E3?= =?utf-8?B?MEl2SE9lcjRXMlZxdDhlS1JPbHhrckhYblphS2hSaEpNMGxoTEVLQ1poSlUr?= =?utf-8?B?cm1PR2VXdUZINzdzNTFadWh2NENYRVBQVEZCZS9mOS9McE8zVDBVbStKSHBE?= =?utf-8?B?VnBoN2g1Z0pvekxnRFFhN1d0aXVjN3ZoeERhcGMvVEZBRExrQkdNWGhLRXpu?= =?utf-8?B?WXhQeHZjQ0h6YlZDVVdYaTNGN2J2QUoxbEdpTFM3NzNMOEkwS256aWcvS3pr?= =?utf-8?B?V2FUWU5QTDVFV0pxQmJ6MnBmNnNHUEp4OUMxZXFDWFpsVENiL0JhNlhhVndN?= =?utf-8?B?U2dBOEV1dXg5U05JRFlyY2ttMGIxcERBQXBhYjhuRzVadUt4MDB5YnhmTXA1?= =?utf-8?B?aXJFZjRPMVUzZzRVODkvZHJBbUVnYVN1OVd5WFZSSXE1M1FPZWRyLzY5WW8w?= =?utf-8?B?S0pQVHE4b1JaRHZ5RGFIYWJxYi9zcDNZK20zUmIzYVlsdUdTaDJxekdjcGdm?= =?utf-8?B?MVMzUTdUMGFCUzZBSnNPMGhNNFdIbzhGS0kwZnlCUGREejlMMkJVRXAzaU9j?= =?utf-8?B?V0lmY0NNd29FVzhjZmw0WE1Wd1N1WjlxTkRwYy8wTzB1ekF2dUhJcVhtQUUy?= =?utf-8?B?QVBqKzlsK0psUDR5aFlWa2VFRzBmMnNoSEJ5WFdYeC9mRWIwTUNpZWFSY0lw?= =?utf-8?B?L2RiL3o5RWQ1NWVmNVh2enp2N3hPUStWeExkT1c1dGtUQUp5N0VETjNwVmQ4?= =?utf-8?B?aDdUM2hVMnFBZXpWVW54dU84TWc4djJLQ3NPR2Y2U1luNWt4KzBJQ0tHSVlN?= =?utf-8?B?ZkZUQjljR2lVWHFlUEJtd1Y5dnpYOFN1WUdGUlZmMU92NDBTc3gvdDRRUlhz?= =?utf-8?B?d3diQXdSMTEyODJOV21OWW4xaUo4UjVNZ0EvWHVxSk1vUEl4OGw2L2hWcHAy?= =?utf-8?B?Qjc2VVNROEQ0VUZXUUlaWE1adEJUbWVBVlZ1Uzk5SmcrZ1hLRmRrcjNJWjFi?= =?utf-8?B?SnVSenRIYllDKy9RODUxaDZtZjF6UXI3OWJUZ0lPN0NydjVkWVpqWHNKMWF0?= =?utf-8?B?Mm9RbjNKbmJyU1J3NitoZEJNeW01TmNRNE5lUVc4TlN1eDJLdnJqd1ZPYVND?= =?utf-8?B?RmVzOWc2azV5Q1VsbkNmNkgzTStWMDhRVU1IVFlpb3A1TjV6NUM4eXlRNTVZ?= =?utf-8?B?VE41OGFJdXNOdm1FODQxWTRRTXRUT3Z2OHhPTitvOFRaMHpGMXhaUUJ5a2J6?= =?utf-8?B?WlY2ODY4L05yb2hRM2VuUG43WUxQaEFYS245cHlKVXZ4bmdJekJPdVdpOGEw?= =?utf-8?B?Ym9KS0VUeWphL0RkVyt2WlgvRWFXNkllNnpFZEQ5QUwzcU1rditEajVtWC9V?= =?utf-8?B?aWtsaWllQ2JtVnZDeHlWaCtudzZCY3ZROHZCci9mc2NUWnI5bzFqV2RGTGZt?= =?utf-8?B?VlNtakxDRGFNbnNyT1NLWGFIN2dKVjJZYWhLL0lYZXV1QXZmeW9XcUZNYUJW?= =?utf-8?B?VnkzTmx6TXdsbEhsaDR0YjZpMzN3RmRVbVFYQWh6OVJkdXFBcUpRTDA5citp?= =?utf-8?B?ZG5hM1NKQ2ljZWN1S3hGTkFXMjcrWTNzVzZpcncxaDdKQ1dWVVY3cmlSeW1U?= =?utf-8?B?V1JuSTRxRXV3WW5kbzNxbVUyTXdvbURqL3hCOStDTEt5ZXg5aFAvYTBwOXRw?= =?utf-8?B?T3M5S2tXV0diYnl0NitUYXJNRUR3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1563; 6:QfboWRZpXMCO69Cv+3yhuN06vl82o3JE5mOdg6Wzn4iCCgs0SeCGC5aaQFpuI9b+KQ1Y2/qVktK6BKqqwEOjR0Osviz41GUgI7I0ArkMOsvbp2tsf30fKY4adhYHLR2uXV0PmHeFA3QtLfz0LHsN/3Tadx4QiiOwl0eUtTUXAk7HCDl5oufJdJnoNkM8Cxys6EH6kzhXIdZ5LW+URMpErCtLqPlX34tu2DR56/7o2FLR+XpxFuKs8TLmgQtvzJZWzsqa24JTCUqItuBI4XvypsfepaNa9kX+5MjyqnNBedl6TK8Y6vJtn2xKUswaJVZOlzQe7oGabpLDPedl3Je8bcFIv0ZowNdO6a6L1ueh0ko=; 5:U1n6c1m8pXWnrYwpOXYBL+/WcujRLNZqIuHiuhNamdL3cjUrUCv5Drw4Rk0vyBKI4cGRBWitlGTpxMqdpGc3PIiwnhxuh41Ynn7Gs7oJ6r/QOIajJLOQZFqMKZdRdCf4XaGntWFdKkNh7Lg6tlzIYhhiW+HKVseRxIiWcsSilPI=; 24:bgYrqTL31yQOLK8J0fVb3acZHENTleo5DjjZxusV7ycmvJOSCZf4rqbUajy6DYMESbVefy2ByPrmm6+iefIwKzTJmOCZpPb1nq9uo2RXBqE=; 7:0S0PBrYQsd2tqdWrtZWczc43pA1cd52ESDaoTcbVsV1Zuny++kJFMeD1euQYyFBmrc7BHPdmCZgVvfrG9yc2xvFiwnspbdqhb9t5wAMru6nQ4xNTg+/DSFpj8Wv59X7+xGOe+Ars88RjSPHKQ9Hxn6aCqH9dRclvi4exs++8Pal5TRRWIfYqk669SswWKuCGeAiJiZsk8eQYQI3AnHW3XZIDg+ry3vSqaKr5h4uAEfZmiGcx2FTnQzhAn9DrB6Ow SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Dec 2017 12:07:54.7084 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a20d32a7-3a80-4e67-abfd-08d54deba0b6 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1563 Archived-At: Subject: Re: [Taps] Draft TAPS minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 12:08:03 -0000 ----- Original Message ----- From: "Ignacio Solis" Sent: Thursday, December 28, 2017 4:59 AM > I'm amazed somebody (other than the chairs) actually goes through and > reads the minutes. As one of those who has not got the time or the money or the ... to be there in person, yes, I do read the minutes. In fact, there are 20 WG in which I might have an interest; of these, to date, seven have posted minutes, or references thereto, on the WG list, so TAPS is doing rather well; and yes, TAPS are good minutes, not a link to or transcription of, Etherpad. And WG that do not produce minutes tend to be those that ignore other aspects of the ways of working of the IETF, such as discussing issues on the WG list, of moving forward based on WG consensus on the list, of allowing time for comment, of acting on comments accepting or rejecting but not ignoring or losing them, .... More subjectively, I think that the WG that do not respect the IETF's way of working tend to produce flawed work, that turns out to have defects sooner rather than later! Tom Petch > I do remember saying something, but I'm hoping it was more eloquent at > the time. (external observers might have classified it as "rat > holing"). I may be a couple of the "?"s. > > I believe I was trying to say that not all applications will know what > is their "intent" with respect to the network. Also, each intent type > will have to be carefully constructed to be useful and not to create > confusion (think of bursty at different time scales). Also (do we > want to get into this?) how will meta/super protocols behave? (think > of QUIC). > > Like I mentioned at some point, I would rather focus on trade-offs > (ordering?) so the system can make choices for me. > > And finally, we should consider giving some guidance of when you > should just "use another `socket`" (probably analogous to "use another > thread"). > > Nacho > > > On Wed, Dec 27, 2017 at 9:18 AM, Christopher Wood > wrote: > > IIRC the person marked as ? in the draft-tiesel-taps-socketintents-01 slot > > was Nacho Solis. > > > > Best, > > Chris > > > > On Thu, Dec 21, 2017 at 10:10 AM Aaron Falk wrote: > >> > >> We’re overdue for filing the minutes from our Singapore meeting. Please > >> give the (very good) notes by Kyle & Tale a look and send comments. > >> > >> —aaron > >> > >> ________________________________ > >> > >> TAPS > >> IETF-100 Singapore > >> Tuesday, November 14, 2017 > >> Room: Olivia > >> > >> Minute takers: > >> Kyle Rose > >> tale > >> > >> Chairs update - 10 min > >> > >> Charter bashng > >> > >> Chris, Aaron, Kyle agreed we need more precise charter language for the > >> WG's transport security function. > >> > >> draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min > >> > >> Brian Trammell > >> > >> Is this an API certification? > >> There's an implicit assumption of ordering in protocols based on number of > >> features > >> From standpoint of feature set that you need to meet, that's the right way > >> to think about it > >> Thinks doc is close to done > >> > >> Tommy Pauly > >> > >> Need to explicitly declare required features for a transport up-front > >> Remove all references to "fallback" because it implies a particular set of > >> preferences/priorities that imply a total order > >> Instead, just catalog protocols by features provided and leave ordering to > >> another doc > >> > >> Spencer Dawkins (responsible AD) > >> > >> Agrees with Tommy > >> > >> Completeness > >> > >> Aaron: What is required for document to be complete? > >> Michael: Tommy to proofread > >> Gabriel: Is CoAP supported? > >> Michael: Minset analysis based on a survey of important existing transport > >> protocols > >> Aaron: Goal of minset is to identify minimum set of functions that a TAPS > >> API should support to cover the basic set of functionality required by IETF > >> protocols. If there's something missing from CoAP, maybe there's stuff in > >> minset that shouldn't be there; alternatively, it may be that CoAP is not > >> expressive enough to be usable through the TAPS API > >> Bob Moskovitz: Purpose of TAPS should be to disconnect the application > >> from the details of the transport, whether or not a constrained transport > >> <---this probably needs clarification > >> Tommy: (missed) > >> Mirja: How to map this to post-sockets? Anything that isn't related to > >> connection establishment or data transfer should be separated out > >> Michael: "Maintenance" covers the configuration aspects of protocols > >> Tommy: Pieces of functionality that are core transport functionality, and > >> then protocol-specific (or model-specific) things that need to be separated > >> out > >> Michael: Need to distinguish between what needs to be said up-front, but I > >> don't like the idea of separating out core functionality from non-core > >> Mirja: There is a box called "configuration" in post-sockets. We need to > >> know what goes in there. > >> Brian: There are things you need to do during connection setup that can't > >> be changed without tearing down connection state: not maintenance. Is this > >> an API specification? It's a specification for APIs that implement TAPS. > >> Would be useful if the knobs available here were organized in a better way. > >> May just need to add another layer to express additional configuration. > >> > >> draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 min > >> > >> Brian Trammel > >> > >> Hard requirement that the protocol stack configuration work without a > >> requirement that a bunch of config be provided. > >> "Configuration" box is what you use to constrain the magic protocol > >> configuration state maintained for a path in the association. > >> Obviate the need for dicking around with sockopts because the defaults are > >> saner. > >> > >> Tommy Pauly > >> > >> IF you use TCP, set this option; IF you choose SCTP, do this. Extra knobs > >> if you need something very specific. > >> Noted another change in the draft is around messages; we like the message > >> abstraction but need to understand how that relates to streams and chunking > >> > >> Praveen from Microsoft > >> > >> How do you reconcile system configuration with app configuration(? not > >> sure I got that right) > >> Brian: the jokey answers is that it sort of looks like cascading style > >> sheets, using predictable overrides to get a final instance configuration. > >> hope to do better than CSS > >> > >> Kyle Rose > >> > >> Re predictability and "too much magic" making things hard to figure out > >> with regard to performance targets etc > >> > >> Brian: Yes really, let's talk about this offline because it'll be like a > >> half hour discussion > >> > >> Accessability of specific aspects of different transport protocol features > >> (maybe non-obvious requirements, like degrading perf on purpose for testing > >> purposes) > >> > >> Brian: the intention is to make it all available through the API if you > >> know which one you're working with > >> > >> Brian > >> > >> Open issues: > >> > >> a protocol-independent carrier state machine > >> how to represent certain transport-specific interactions > >> > >> Bring this into the wg now? > >> > >> critical mass of Abstract interface proposals now > >> ready to take the creative leap to design the API > >> Aaron: actually this does sound like a charter change for architecture > >> name?: In a way this is looking at "maxset" rather than "minset" > >> Michael Wetzl: the reason the charter is so conservative was because > >> people couldn't really agree so had to be pared down. Agree that it is good > >> to have a higher layer, but concerned about the implementability > >> Aaron: moving into the territory of a charter revision, which we're not > >> going to talk about right now. mic closed. > >> > >> draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 min > >> > >> Automated Transport Option Selection (see slides) > >> Desire to use same set of (essential) keywords no matter what programming > >> language is being used > >> Main questions: is this easy enough and useful enough to devs? sufficient > >> to express the usual set of intents? what's missing? > >> Michael Wetzl: > >> > >> could be missing out some things that might not be obvious from looking at > >> current protocols > >> > >> ?: > >> > >> How to app dev really know how to understand things like the implications > >> of burstiness? or what bitrates it is using? > >> Philip: An app should have a fairly intuitive understanding of whether it > >> is constant or bursty, even if it doesn't know the specifics of volume > >> > >> Praveen: > >> > >> Think it really needs some way of indicating the pattern of traffic (eg, > >> send/receive messages) > >> Philip: +1 > >> > >> Tommy: > >> > >> Very difficult area to get right; we're going to need to expose the > >> protocol knobs > >> Definitely want to see this discussion happening in the WG even if this > >> particular set of options is torn down. Expect it to be a tricky, difficult > >> discussion > >> > >> Aaron Falk: > >> > >> Have you implemented it? > >> Philip: limited implementation on top of BSD Sockets > >> This does go back to the ATM classification discussions and previous > >> attempts to categorize what is expected of the network > >> This table is an "attractive nuisance" for criticism and a good starting > >> point > >> Philip: agreed, it is just a starting point and not being proposed as the > >> end point > >> > >> ? > >> > >> The table worries me because it seems far to easy to rathole on each > >> element of it > >> Aaron: are there semantics from the ABT world that would be useful? > >> > >> ? > >> > >> An issue in the table that "intents" are about things the app is > >> signalling what it intends to do, but other things there are not really > >> intents but something the app desires > >> It isn't useful for apps to just only be able to say "give me all the best > >> performance always" but rather to have to indicate what the trade-offs are > >> > >> Mirja Kuhlewind: > >> > >> Agree with ?previous speaker. Not really sure what does make sense to > >> specify here. > >> > >> Brian: > >> > >> "Can you go back to the ATM table [slide] again?" > >> Two main issues with this; the further right you get the happier I am and > >> to the left the sadder. It's sort of like a heat map of how I like the > >> table. > >> Table helped clarify for me the separations that are needed > >> Two distincts groups of people in this room, apps chauvanists and > >> transport chauvinists, and these are in tension for designing the > >> architecture. really need to find the balance. > >> This way is application chauvanist (and I'm [Brian] also application > >> chauvanist) but we need to call that out > >> > >> David Schinazi > >> > >> Another type of chauvanist, an engineering chauvanist, which I am > >> Definitely value in some sort of registry for different types of intents > >> and showing how they could be used > >> Premature to have a laundry list of all the things we might possibly want > >> without an understanding of how we really want to use them (like burstiness) > >> > >> Gorry Fairhurst: > >> > >> I like the list; I think the list should be bigger, but the datatype > >> values should mostly be binary (enums) > >> > >> Philip: > >> > >> Open question: is this the way the IETF describes Abstract APIs? > >> > >> draft-pauly-taps-guidelines-01 - Tommy Pauly, Apple -25 min > >> > >> See slides, on the topic of racing connections > >> Tommy ... didn't even get off the title slide before Colin was @ the mic > >> Colin > >> > >> Scoping question: when you say racing do you mean Happy Eyeballs or things > >> like ICE as well? > >> Tommy: mostly from Happy Eyeballs perspective > >> > >> Aaron: > >> > >> Is split VPN definining separate peths? > >> Tommy: conceptually yes > >> > >> Colin > >> > >> Trying to still figure out the difference between a path and endpoints > >> ICE is about determing what works > >> Tommy: which yes is also what this about, and we do need more work w/ICE > >> > >> Brian > >> > >> (on Avoiding Ossification slide) these things seem to be mutually > >> exclusive but maybe not intrinstically so but rather in your approach. not > >> sure how to fix it though. > >> Tommy: in the context of the current app dev cycle, taps is way better > >> than BSD sockets api used to be, way easier to just turn on a bit than > >> change the whole model > >> Re what should be raced or not raced, advantages to doing it tree oriented > >> rather than sequence oriented > >> > >> Colin > >> > >> On the ossification point, in the past we were trying to be general > >> (SOCK_STREAM) but never really was, whereas we do avoid some of that with > >> taps by already starting with more than one underlying choice > >> > >> Wolfgang Beck > >> > >> It is interesting that most (all?) IETF docs that talk about what protocol > >> an app should use never talk about general charateristics like stream/dgram > >> but rather specifically call out TCP or UDP > >> > >> Colin > >> > >> Quick followup on the ICE point, you may have to hook this racing into the > >> application state > >> > >> Spencer > >> > >> Interested in the comments about modern dev cycles vs historic, and would > >> like this explored more before last call > >> Tommy: the tail of people who are not pushing new updates to their code > >> are probably not going to adopting anything beyond BSD sockets anyway > >> > >> draft-fairhurst-taps-neat-00, Gorry Fairhurst, University of Aberdeen -20 > >> min > >> > >> See slides > >> Zahed: Who is setting up the policy? > >> Gorry: Internal interface in neat, from the policy manager > >> Personally pefer binary keywords for desired characteristics, like "low > >> latency", over specific metrics > >> Slight concerns about making things overly complicated into the neat api > >> Strongly believe taps API has to be callback based to support the expected > >> mechanisms of the current app dev world > >> Aaron > >> > >> Can you say anything about the example apps? > >> Gorry: well we can send bytes backwards and forwards, so that's good > >> right? And Mozilla has something working with it > >> > >> Mirja > >> > >> The base architecture should be a message not a stream > >> Gorry: totally agree with you > >> Still some fuzziness around transport/session layer > >> > >> Kyle > >> > >> Minor quibble on making it event driven, because sometimes you don't > >> really want to use that style (maybe using imperative/blocking, maybe using > >> CPS) > >> What you want is the API to express various programming models, maybe with > >> the event-based model as the foundation for others if it's sufficiently > >> expressive to capture all widely-used models > >> Gorry: system is based on libuv, and yes maybe we could do other models on > >> top of that as the substrate > >> > >> Tommy > >> > >> We definitely don't want blocking to be the main API but there are > >> multiple models for asynchronousity > >> Abstract API should absolutely not have anything specific about how to > >> implement it, just the features needed > >> > >> Wolfgang Beck > >> > >> ? ... sorry missed that first comment (so did I) > >> Issues about limiting th queue size is not that useful without > >> understanding other issues w.r.t rate / etc. What we really want is more > >> like the Van Jacobsen model with something like packet soldiers(?) > >> Gorry: you're a realtime person, aren't you? > >> Yes so coming from that perspective > >> > >> Zahed > >> > >> Gorry: See happy eyeballs as "how do you decide on a final transport?" But > >> then you have the problem of choosing the candidates, and that's the bit > >> where the policy engine(?) fits in. > >> > >> Gorry > >> > >> Deciding on an architecture will help a lot with nailing down terminology > >> > >> Discussion on charter item 3 - 10 min > >> > >> Aaron > >> > >> Look at the history of the group, and how the possibility of rechartering > >> was considered early on based on initial results > >> Aaron's feelig the love > >> Let the record show: Aaron is happy. > >> My gut tells me that there is a useful common architecture can be > >> extracted from this. What does the group think? > >> > >> Brian Trammel > >> > >> We basically do have some architectures, so can be chosing to continue > >> that as wg business. Like postsockets is an architecture > >> Aaron: I would be pleased to hear whether the people who work on other > >> projects (neat) would be good with working with that > >> > >> Mirja > >> > >> The different projects have different levels of abstraction, so we should > >> be deciding on what level of abstraction to use > >> Should pursue as unified, not two separate abstraction layers > >> > >> Michael > >> > >> Essential agreement with Mirja > >> Aaron: implementation experience is extremely valuable for validating > >> these ideas > >> > >> Gorry > >> > >> Not incompatible; just different levels > >> > >> Anna > >> > >> Neat is not abstract enough but postsockets probably too abstract, would > >> be good to find something in the middle > >> > >> Tommy > >> > >> We have enough experience in the room with various implementations. Agree > >> this is at a very abstract level. There's a neat implementation doc saying > >> "this is how we decided to implement it". I could produce one of those also > >> for how we (Apple) implemented it. > >> What I want to see out of postsockets is something that is forward looking > >> enough to still be relevant in 10 years but still implementable now > >> > >> --over time-- > >> Mirja > >> Phillip > >> > >> Good to see that postsockets/neat is moving toward a common language and > >> want to keep them separate for now to see how they might naturally come > >> together over time > >> > >> Tommy > >> > >> One thing that could help speed up that coming together is a terminoogy > >> document to solidify that common language (eg, to define what a path is, > >> etc) > >> > >> Aaron thinks the bar is low for defining terminology. Aaron is apparently > >> new to the IETF > >> > >> --fin > >> > >> _______________________________________________ > >> 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 > > > > > > -- > Nacho - Ignacio Solis - isolis@igso.net > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >