Re: [Taps] Concluded (Re: Consensus call on arch, interface, and impl, ACTION DUE by February 13th)

[Gorry Fairhurst]

On 14/02/2024 23:12, Reese Enghardt wrote:

Dear TAPS,

The consensus call has concluded.

The chairs have not seen any comments other than Tommy's words of 
encouragement below, thank you Tommy!


So we'll conclude that there are no objections and that the documents 
are ready.


Thanks again, all!

Best,
Reese


Many thanks - these documents have improved significantly through the 
inputs and reviews of many different people, and the careful review by 
the IESG in the last stages -- thanks again to everyone who helped 
complete these documents!


I look forward to seeing them published and used!!

Gorry




On 2/7/24 07:14, Tommy Pauly wrote:
As an author on these documents, I do want to reiterate what Reese 
said — thanks to all for the work on polishing these by everyone who 
contributed! I do think these are ready to go, and have been improved 
by the IESG feedback.


If you’re not an author but reading along, please do check the latest 
versions and verify that these look good!


Thanks,
Tommy


On Jan 30, 2024, at 6:59 AM, Reese Enghardt  wrote:

Dear TAPS Working Group,

The document authors have worked through all the IESG reviews and 
made a number of revisions to our three core documents.


The authors, shepherds, and chairs believe that the revision process 
is now complete.


We are now running a two-week consensus call on all three documents:

- draft-ietf-taps-arch 
https://datatracker.ietf.org/doc/draft-ietf-taps-arch/


- draft-ietf-taps-interface 
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/


- draft-ietf-taps-impl 
https://datatracker.ietf.org/doc/draft-ietf-taps-impl/



Please send any comments to taps@ietf.org by February 13th.

Thank you again for the great work everyone.

Best,
Reese (for the TAPS chairs)

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

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


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



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

Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)

[Gorry Fairhurst]

I also agree with what was threashed out, over quite some time, in the 
TAPS WG. I agree that someone can have a Transport Services system and 
could implement a different API to this - if that is what someone 
needed. The two are independent in this way, and other SDOs or companies 
could in future to cite the system spec aka Arch - and develop 
components of that API, Policy, whatever. I recall that being able to 
cite this spec was also important in the choice of standards track for 
Arch.


I'm less sure one can have an API without a set of system components 
beneath, but that likely means if someone wants to implement the API, 
they do need to read both Arch & API, and also the examples in 
Implementation. If you only want to use the API, you could start with 
API, and just a skim of Arch.


Last, I do see that if we think people will read the word "Architcture" 
and think of a particular type of document, then that might not be the 
best choice of word for the title. So, I'm OK with changing that, and 
suggest the simplest could be omitting the word "Architecture", leaving 
something like "The Transport Services System", or whatever, - confusion 
by title is the worst outcome!


Gorry

P.S. Thanks everbody for comments - we're working through these and 
solutions for most will soon be realised in the github, this was 
valuable (I also revisited some earlier area reviews - and we'll also 
confirm these were correctly resolved in the latest revision).



On 05/09/2023 10:11, Brian Trammell (IETF) wrote:

Hi, all,

+1 to everything said in this thread by TAPS folks (and +2 thanks to 
Michael for the history).


IMO there’s a pattern of confusion in this discussion between 
*prescriptive* and *descriptive* architecture, which I’ve seen before, 
as the term “architecture” has been AIUI used in the IETF space 
without qualification for both purposes.


Prescriptive architecture: “Here are the boxes and lines you *need to 
have*, implementations with missing, extra, or otherwise-defined boxes 
are noncompliant”. These architectures are generally requirements with 
a different label on them (“REQUIREMENTS and architecture”, if you 
will). Obviously, in the absence of protocol compliance officers, 
prescriptive architectures are only “enforceable” in the extent to 
which the underlying protocols are defined with a strong assumption 
s.t. any violation of said boxes leads to interoperability problems or 
violations of security properties.


Descriptive architecture: “We have defined a protocol or set of 
protocols which foresees a potential division of responsibility 
between and/or within protocol actors. This architecture serves to 
provide a basic terminology such that the concepts in the protocol are 
understandable and implementable”.


The TAPS architecture is of the latter form, or is at least 
(emphatically) intended to be; indeed, I don’t think it’s worth the 
time to write prescriptive arch documents in a world where the 
implementors don’t sit in your reporting chain. To the extent that 
descriptive architectures impose requirements, they are requirements 
that are (implicitly) imposed by the interface definition *anyway*. 
IIRC we did consider such a split (informational architecture, 
normative interface) but thought it would be less readable and 
understandable, as you couldn’t really stack one on top of the other 
neatly.


As for the label we stick on the document, as Mirja says I don’t think 
it matters much, but since the main point of the (descriptive) arch 
document is (descriptive) arch, I have a slight preference to leave it 
as is.


I’ll note that the architecture and interface documents have 
independent utility, in that there is value in a transport service 
layer designer/implementor reading and adopting the TAPS architecture 
*without* hewing to the letter of the interface document, as one (and 
perhaps, “the whole”) point of the TAPS effort is to change the 
“shape" of the application-transport interface to allow 
transport/internet layer implementations at the endpoint more 
flexibility in the fulfillment of application intent given the present 
and future world of transport innovation opened by e.g. QUIC.


Cheers,

Brian


On 4 Sep 2023, at 23:04, Aaron Falk  wrote:

I don't have too much to add beyond Mirja's point.  The working 
group felt strongly that TAPS could not be correctly implemented 
without reading the architecture document.  Further 
https://www.ietf.org/standards/process/informational-vs-experimental/ 
says:


An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation.


Neither of which accurately describe the doc.  Like Mirja, I'm open 
to tweaking the title although I think something like  "An 
Architecture for Transport Services (Read This First)" would be more 
useful than adding the term "Requirements" but YMMV.


--aaron

On Mon, Se

Re: [Taps] TAPS Dinner/Lunch at IETF117

[Gorry Fairhurst]

On 12/07/2023 19:41, Reese Enghardt wrote:

Hi,

On 7/12/23 11:10, Tommy Pauly wrote:
I’d be happy to meet up with TAPS folks for Monday/Tuesday/Wednesday 
lunch slots, depending on availability of everyone!


That would work for me, too.

Best,
Reese

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


For me: Monday seem best, then Tuesday, then Wednesday.

Gorry

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

Re: [Taps] Heads-up: Should we conclude TAPS after the three docs are done?

[Gorry Fairhurst]

On 15/03/2023 20:52, Michael Welzl wrote:

Hi !

I would love to have an interim. These are the things that I personally would 
like to discuss:
1) what could we now do to foster deployment of this?
2) is anyone really planning to write an http mapping document, ever?  this 
would have to be (and should be easy for!) someone with the right 
implementation experience…….   ahem…
3) like 2), but s/http/quic

If the WG closes, where else could 2) and 3) happen?  Does this relate to item 
1) somehow?

If everyone just shrugs their shoulders to all of these questions (as I do), I 
guess this could be a short interim followed by closing the group. Just my 2 
cents.

Cheers,
Michael


I think we previously said we could fo 2,3 after we had the base drafts 
published - I expect that is going to be soon, and I think once that is 
done we ought to have that interim and talk about this!


Gorry




On Mar 15, 2023, at 4:35 PM, Reese Enghardt  wrote:

Dear TAPS,

As we are moving towards finishing the three core documents, the next step will 
be to recharter or conclude.

We have talked about possible further milestones related to mapping documents, 
and we have a few related issues on the Github 
(https://github.com/ietf-tapswg/api-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Amappings).

However, we have not seen much activity on this topic since IETF 113, and we 
have no related currently active documents.

I wanted to give you a heads-up that, given this state, the chairs are 
wondering if it'll be time to conclude TAPS once the core documents have made 
their way to the RFC Editor, unless we see evidence of substantial interest and 
activity regarding further milestones.

Nothing has been decided yet, and we will be happy to discuss this question.

TAPS is not meeting at IETF 116, but we can consider scheduling a virtual 
interim meeting or a WG meeting at IETF 117 if we have content for a fruitful 
discussion.

Please let me know your thoughts.

Best,
Reese

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

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



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

Re: [Taps] Normative language change in the Interface document (Re: I-D Action: draft-ietf-taps-interface-19.txt)

[Gorry Fairhurst]

On 14/03/2023 10:24, Mirja Kuehlewind wrote:

Hi all,

first thanks for all the work!

I reviewed the diffs below and actually have two questions on normative 
language, not on the content but on the use of normative language.

In the arch doc, it's this sentence here

" An application SHOULD NOT depend on
  specific caching behaviour, instead it ought to 
explicitly request
  any required or desired properties via the Transport 
Services API."

I don't disagree with this sentence but use of normative language seems a bit awkward. I 
would recommend to either use lower case should or maybe say "SHOULD NOT rely 
on" instead because that seem more like an active choice.


I'm unsure that I precisely understand the diference between /rely upon/ 
and /depend upon/, in this sentence I'd be happy either with either word 
- "rely" would be fine for me.



For interface we have this sentence:

"An Endpoint MUST NOT be configured with multiple identifiers of the
   That is, an endpoint cannot have two IP addresses specified.  Two
   same type."

However, this is not a requirement but a matter of fact. This is how we in this 
document define an endpoint - it can only have one identifier. I missed this 
change on github but I don't think it's correct.


I think (if I understand your argument) that you say a design will 
prevent this because that is how we define Endpoint. I'd agree a design 
of system cannot allow this, but then thenis it any better to state the 
design requirement as "The design of the API MUST NOT permit an Endpoint 
to set multiple identifiers of the same type."


Gorry



Mirja




On 10.03.23, 12:54, "Taps on behalf of Michael Welzl"  wrote:

 Hi,

 FWIW, I agree with all of these changes.
 I’m an author of the second and third document, so for these it is 
obvious, but I’m not an author of the first one.

 Cheers,
 Michael



 > On 10 Mar 2023, at 01:26, Reese Enghardt  wrote:
 >
 > Dear TAPS,
 >
 > As you may have seen, our three documents were updated to address 
Zahed's AD review comments (Thank you to everyone involved!).
 >
 > Please note that there were normative language changes in the Interface 
document.
 >
 > If you have any questions about or any objections to these changes, 
please respond to the list within the next two weeks, i.e., by Thursday March 
23rd, 5pm PT. (This is Thursday before IETF 116.)
 >
 > If we don't hear anything by this date, we will assume that there is WG 
consensus on these changes.
 >
 > For your convenience, here are the diffs for all three documents:
 >
 >
 >https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-arch-16
 >
 >https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-interface-19
 >
 >https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-impl-15
 >
 >
 > Best,
 > Reese
 >
 >
 > On 3/9/23 10:01,internet-dra...@ietf.org  wrote:
 >> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 >> This Internet-Draft is a work item of the Transport Services WG of the 
IETF.
 >>
 >> Title   : An Abstract Application Layer Interface to 
Transport Services
 >> Authors : Brian Trammell
 >>   Michael Welzl
 >>   Theresa Enghardt
 >>   Godred Fairhurst
 >>   Mirja Kuehlewind
 >>   Colin Perkins
 >>   Philipp S. Tiesel
 >>   Tommy Pauly
 >>   Filename: draft-ietf-taps-interface-19.txt
 >>   Pages   : 91
 >>   Date: 2023-03-09
 >>
 >> Abstract:
 >>This document describes an abstract application programming
 >>interface, API, to the transport layer that enables the selection of
 >>transport protocols and network paths dynamically at runtime.  This
 >>API enables faster deployment of new protocols and protocol features
 >>without requiring changes to the applications.  The specified API
 >>follows the Transport Services architecture by providing
 >>asynchronous, atomic transmission of messages.  It is intended to
 >>replace the BSD sockets API as the common interface to the transport
 >>layer, in an environment where endpoints could select from multiple
 >>interfaces and potential transport protocols.
 >>
 >>
 >> The IETF datatracker status page for this Internet-Draft is:
 >>https://datatracker.ietf.org/doc/draft-ietf-taps-interface/
 >>
 >> There is also an HTML version available at:
 >>https://www.ietf.org/archive/id/draft-ietf-taps-interface-19.html
 >>
 >> A diff from the previous version is available at:
 >>https://a

Re: [Taps] Normative language change in the Interface document (Re: I-D Action: draft-ietf-taps-interface-19.txt)

[Gorry Fairhurst]

On 10/03/2023 14:57, Brian Trammell (IETF) wrote:

hi Reese, all,

Apologies I haven’t been around on the answering-of-comments; it’s been a rough 
month. Thanks, all, for getting these revs of the documents out. I’ve reviewed 
the changes.

- Arch changes are good, modulo the following non-blocking comment:

I’m not convinced of the value of the glossary of terms, as it forwardrefs 
basically the entire document, and some of the definitions are so generic as to 
be potentially confusing (e.g. Event), so I think putting these up front 
reduces the document’s approachability and readability.  I understand that some 
people like these (and other standards orgs make them mandatory, hi ETSI), so I 
won’t fight it.


Mea cupla on this, and I did recall your thoughts when we discussed at 
one of the TAPS interims. At first I didn't feel persauded, but as I 
tried to reset my head to someone who had never read these IDs before, I 
began to think this could be really valuable to give some initial 
context to the many terms we use across the documents. The text is 
identical or "thinned" versions of later text.


If this glossary is thought useful - which I now personally think it is, 
but others are free to comment  - I'd be really quite OK with this 
"glossary" starting with a sentence that says each of these terms is 
defined later in the document, in other words - hinting strongly don't 
bother with this if you know what you are reading




- Interface changes are good.

- Implementation changes are good.

Cheers,

Brian


On 10 Mar 2023, at 01:26, Reese Enghardt  wrote:

Dear TAPS,

As you may have seen, our three documents were updated to address Zahed's AD 
review comments (Thank you to everyone involved!).

Please note that there were normative language changes in the Interface 
document.

If you have any questions about or any objections to these changes, please 
respond to the list within the next two weeks, i.e., by Thursday March 23rd, 
5pm PT. (This is Thursday before IETF 116.)

If we don't hear anything by this date, we will assume that there is WG 
consensus on these changes.

For your convenience, here are the diffs for all three documents:


https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-arch-16

https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-interface-19

https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-impl-15


Best,
Reese


On 3/9/23 10:01, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Transport Services WG of the IETF.

 Title   : An Abstract Application Layer Interface to Transport 
Services
 Authors : Brian Trammell
   Michael Welzl
   Theresa Enghardt
   Godred Fairhurst
   Mirja Kuehlewind
   Colin Perkins
   Philipp S. Tiesel
   Tommy Pauly
   Filename: draft-ietf-taps-interface-19.txt
   Pages   : 91
   Date: 2023-03-09

Abstract:
This document describes an abstract application programming
interface, API, to the transport layer that enables the selection of
transport protocols and network paths dynamically at runtime.  This
API enables faster deployment of new protocols and protocol features
without requiring changes to the applications.  The specified API
follows the Transport Services architecture by providing
asynchronous, atomic transmission of messages.  It is intended to
replace the BSD sockets API as the common interface to the transport
layer, in an environment where endpoints could select from multiple
interfaces and potential transport protocols.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-taps-interface-19.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-interface-19


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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


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

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



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

[Taps] IPR: draft-ietf-taps-arch shepherd comments

[Gorry Fairhurst]

On 19/10/2022 18:03, Michael Welzl wrote:

[ cc’ing the chairs but not the list: these things are truly too boring ]


Dear authors of draft-ietf-taps-arch,

I have now gone through the template (questionnaire) for shepherds for 
this document. In the process, the following things have come up:



1) IPR:

"Have reasonable efforts been made to remind all authors of the 
intellectual
   property rights (IPR) disclosure obligations described in [BCP 
79][7]? To

   the best of your knowledge, have all required disclosures been filed?”
https://www.rfc-editor.org/info/bcp79

=> I can write “Yes” in good faith after having sent this email, and 
not getting any indication from anyone of you about IPRs. If there is 
anything, act immediately please.



I know of no IPR relating to any of the 3 TAPS drafts.

Best wishes,

Gorry Fairhurst

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

Re: [Taps] Some comments on draft-ietf-taps-impl-12

[Gorry Fairhurst]

On 05/08/2022 21:40, Fernando Gont wrote:

Hi, Gorry,

Thanks for all your responses! In-line

On 5/8/22 12:00, Gorry Fairhurst wrote:


Section 4.7.2.:

On platforms with facilities to create a "virtual connection" for
connectionless protocols implementations should use these mechanisms
to minimise the handling of datagrams intended for already created
Connection objects.


I don't necessarily disagree, but you should probably elaborate here 
-- e.g., on one hand, "stateless" is good in the sense that you 
don't tie system resources unnecessarily. However, it's also more 
prone to spoofing, to the extent that an attacker might require "a 
lot of work" from a server without even proving that it can receive 
the return packets.


I'm not quite sure what you are asking here. What I think was 
intended was very similar to the way UDP sockets in BSD can be used 
with "connect", is there something else you were expecting to see in 
the text?


Looks like I got confused -- my bad, sorry! -- No changes expected here.

Thanks,


OK, no problem we'll cross this one off. Thanks for the review though.

Gorry

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

Re: [Taps] Some comments on draft-ietf-taps-impl-12

[Gorry Fairhurst]

Thanks, I added trhese as issues #1054-1057, so we don't forget these 
topics.


... I also have one specific query below...

On 05/08/2022 12:01, Fernando Gont wrote:

Folks,

Some comments/feedback on the aforementioned I-D:

* Section 4.2.1.1. Local Endpoint candidates

You should probably consider PCP/UPnP here. see e.g. 
https://www.ietf.org/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-support-for-firewall-traver 




* Section 4.3.3. Failover

I haven't recently checked what's the status of current TCP 
implementations. But at least at some point in time there are some 
that would failover more quickly based on notifications from the 
network (e.g., ICMP errors). see: 
https://datatracker.ietf.org/doc/html/rfc5461



Section 4.7:

4.7. Implementing listeners When an implementation is asked to 
Listen, it registers with the system to wait for incoming traffic to 
the Local Endpoint. If no Local Endpoint is specified, the 
implementation should use an ephemeral port.


Note: there are implications of using a port number from the ephemeral
port range. See e.g. Section 3.1 of
https://www.rfc-editor.org/rfc/rfc6056.html#page-8

TL;DR; The general idea is that one should use the same range to pick
port for outgoing connections than to pick ports for listening endpoints.



If the Selection Properties do not require a single network
interface or path, but allow the use of multiple paths, the Listener
object should register for incoming traffic on all of the network
interfaces or paths that conform to the Properties. The set of
available paths can change over time, so the implementation should
monitor network path changes, and change the registration of the
Listener across all usable paths as appropriate. When using multiple
paths, the Listener is generally expected to use the same port for
listening on each.


I'd probably stress this a bit more e.g., quite often the port needs 
to be registered somewhere (e.g., directory service), so having 
different ports for each interface would seem problematic.




Section 4.7.2.:

On platforms with facilities to create a "virtual connection" for
connectionless protocols implementations should use these mechanisms
to minimise the handling of datagrams intended for already created
Connection objects.


I don't necessarily disagree, but you should probably elaborate here 
-- e.g., on one hand, "stateless" is good in the sense that you don't 
tie system resources unnecessarily. However, it's also more prone to 
spoofing, to the extent that an attacker might require "a lot of work" 
from a server without even proving that it can receive the return 
packets.


I'm not quite sure what you are asking here. What I think was intended 
was very similar to the way UDP sockets in BSD can be used with 
"connect", is there something else you were expecting to see in the text?




Thanks!

Cheers,


Gorry

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

Re: [Taps] Some comments on draft-ietf-taps-interface

[Gorry Fairhurst]

On 05/08/2022 11:31, Fernando Gont wrote:
6.2.13. Use Temporary Local Address Name: useTemporaryLocalAddress 
Type: Preference Default: Avoid for Listeners and Rendezvous

Connections. Prefer for other Connections. This property allows the
application to express a preference for the use of temporary local
addresses, sometimes called "privacy" addresses [RFC8981]. Temporary
addresses are generally used to prevent linking connections over time
when a stable address, sometimes called "permanent" address, is not
needed. There are some caveats to note when specifying this property.
First, if an application Requires the use of temporary addresses, the
resulting Connection cannot use IPv4, because temporary addresses do
not exist in IPv4. Second, temporary local addresses might involve
trading off privacy for performance. For instance, temporary
addresses can interfere with resumption mechanisms that some
protocols rely on to reduce initial latency.


The terminology employed in this subsection seems a bit confusing, or 
at least deviates from what we normally use in v6-circles. I suggest 
taking a look at RFC7721 -- certainly not flawless, but it was 6man's 
shot to try to agree on terminology. For example, I don't think we use 
"permanent" and "stable" interchangeably.


e.g. the "Local" in "useTemporaryLocalAddress" might be misleading to 
some. -- e.g. could be interpreted as related with link-locals or ULAs.


Aside, I believe there's much more to dig regarding address properties.
e.g., we have given it a shot at: 
https://www.ietf.org/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html 



e.g., the choice of ipv6 addresses has more than one dimension... and 
there are tradeoffs involved, which IMHO deserve discussion.


And aside from the regular address systems normally configure, if one 
were to specify an API one would probably want to provide a mechanism 
for apps to be able to request sole/single-use addresses (.e.g., one 
address per app or container).


I created issue: Temporary Local Address #1053 in github so we don't 
loose this issue,


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

Re: [Taps] Reviewing taps-impl-12

[Gorry Fairhurst]

On 19/05/2022 12:47, Christian Amsüss wrote:

Hello taps-impl authors,

I've had a look at Implementing Interfaces to Transport Services from
the point of view of a curious observer of the TAPS ecosystem without
actual hands-on experience. (Also, I thought I'd review this for the ART
review team -- I wasn't assigned, but still kept ART area issues in
mind, and none were even remotely encountered).

* "Connection establishment is only a local operation for a Datagram
   transport (e.g., UDP(-Lite))": I think the criterion is not Datagram
   transports but "transports without a handshake" or "connectionless
   protocols" as it is used later in the document.

* "In effect, each leaf node will send the same early application data,
   yet encoded (encrypted) differently on the wire.": There has been a
   warning on the privacy implications of using the same token on
   different paths; doesn't sending an identical 0-RTT message racingly
   on multiple transports cause similar correlation issues?

* Framers: What is the difference between the Final message property and
   the separate IsEndOfMessage event argument?

   Also there, the term MessageContext could use a definition.

* Framers: The  paragraphs in Defining Message Framers and later
   might be formal language or pseudocode, I can't tell. It might help if
   the introduction stated something around names and signatures of
   signals and functions being expressed in pseudocode, and that
   identifiers in implementations are expected to be similar to those but
   following the conventions of the language they are implemented in.

* Is the content of messages always bytes? I certainly got that
   impression, but didn't see it explicitly either. (The "protocols that
   expose byte-streams" have that property visible in their name). When
   framers are used a lot, I can envision that at some point a message
   might not use data bytes at all any more, as all information in the
   underlying message is being dissected into protocol specific
   properties.

* UDP, ConnectionError: Would those soft errors contain additional
   information about the ICMP error code, and can an application expect
   to find the (partial) original datagram in the error?

* (More out of curiosity, with no expectation that this would find its
   way into the text unless you think I've hit a bug): In UDP Multicast
   Receive, which kind of ICMP notifications can come in there that would
   constitute a ConnectionError -- given that this transport does not
   send (and would thus usually not trigger any)?

* The most recent changes on the two linked Python implementations had
   me briefly worry that they might be out of date with their last
   changes around 2019/2020 -- but comparing -12 with -06 it seems that
   the document has been stable for quite a while (with many changes
   appearing editorial.

   This nicely matches my the overall impression of this document, which
   is that it looks mature and ready to implement.

Best regards, and thank you for the continuous work on this
Christian


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


This is very useful!!  Thank you for sending these.

I have created 5 corresponding issues in the WG github for these 
comments, and expect they can also be discussed there - please do 
follow-up on proposals and comments.


Best wishes,

Gorry

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

Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2021-12-08

[Gorry Fairhurst]

aha ... me too,

if nothing else, jitsi?

Gorry

On 08/12/2021 16:04, Tommy Pauly wrote:

Yeah, I’m getting “unauthorized”...


On Dec 8, 2021, at 8:03 AM, Martin Duke  wrote:

Meetecho login is down, so we may want to find ourselves an alternate app

On Wed, Dec 8, 2021 at 7:51 AM Brian Trammell (IETF) 
 wrote:


Hi, all,

Will be a bit late to this meeting, $dayjob thing intervenes...

See you all soon, cheers, B

> On 30 Nov 2021, at 18:17, Theresa Enghardt 
wrote:
>
> Dear TAPS,
>
> Reminder that we're having an interim meeting next week on
Wednesday at 16:00 UTC.
>
> To join:

https://meetings.conf.meetecho.com/interim/?short=5671c27c-adf1-49c2-b931-f95d04441c30
>
> Hope to see you there!
>
> Best,
> Reese
>
>
>
> On 10/22/21 10:43 AM, IESG Secretary wrote:
>> The Transport Services (taps) WG will hold
>> a virtual interim meeting on 2021-12-08 from 11:00 to 13:00
America/New_York (16:00 to 18:00 UTC).
>>
>> Agenda:
>> To join:

https://meetings.conf.meetecho.com/interim/?short=5671c27c-adf1-49c2-b931-f95d04441c30
>>
>> Agenda:
>> * Issues: https://github.com/ietf-tapswg/api-drafts/issues
>> * PRs: https://github.com/ietf-tapswg/api-drafts/pulls
>>
>> Information about remote participation:
>>

https://meetings.conf.meetecho.com/interim/?short=5671c27c-adf1-49c2-b931-f95d04441c30
>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

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

___
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


--
G. Fairhurst, School of Engineering
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Review of draft-ietf-taps-arch

[Gorry Fairhurst]

These all look reasonable, and most easy to resolve. Now as github issues:-)

Gorry

On 20/10/2021 15:00, Aaron Falk wrote:


Hi Michael-

Thanks for the review. Glad to see the doc hasn’t ‘aged’ much as the 
others have been refined. Let’s assume I dropped the ball on reminding 
you about the review. :)


--aaron

On 20 Oct 2021, at 9:31, Michael Welzl wrote:

[ I don't think this is worth time at today's interim. These
should generally be quite quick to address. ]


Hello TAPS!

A few interims ago I volunteered to review draft-ietf-taps-arch.
I'm obviously biased in everything TAPS, yet I'm not an author of
this particular draft, nor have I read it in a long time...
After volunteering, I expected to receive an email pinging me
about it. I never did, and now I think that I shouldn't have
waited for an email - I believe that this was a misunderstanding.
Be that as it may, now I have finally reviewed it :)

This review concerns the "Editor's copy" version at
https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-arch.html

as of 11:51 (my time) on 19. 10. I believe that it includes the
latest PR from Gorry, and it probably matches the latest version
at the time of writing this.
I'll just put all my comments here in sequence of appearance in
the document instead of grouping them and opening issues, and
leave it to the document authors to decide what's a nit and what's
a content change that warrants further discussion - I trust you to
"do the right thing" (tm) (*truly* a trademark, though not mine :-) ).


Without further ado, here come my comments:


Introduction paragraph 2: here we have 3 occurrences of "provide".
I would replace the middle one - e.g.: "...reusable architecture
that offers a common interface ..."

Section 1.2, item 3, starting with "Section 4 presents...": I
believe that the last ( = second) sentence of this item must have
ended here by error, it seems out of place ("The Preconnection
allows applications..."), and I think it can safely be removed.

About the last sentence in item 4, see:
https://github.com/ietf-tapswg/api-drafts/issues/939


Section 2, right below Figure 2:
"The Transport Services API [I-D.ietf-taps-interface] defines the
interface for an application to create network connections and
transfer data."
=> Should this be "Connections" instead of "network connections" ?

Section 2.1, paragraph 2, last line: "... made explicit in
sockets." seems strange. Should this be "in the sockets API." ?

Section 2.2 paragraph 1, this sentence:
"While TCP does indeed provide the ability to send and receive
data as streams, most applications need to interpret structure
within these streams."
Two issues here. First, I would switch to singular because TCP is
not a multi-streaming protocol. I.e., change this to:
"While TCP does indeed provide the ability to send and receive
data as a stream, most applications need to interpret structure
within this stream."
Second, is "stream" a known concept? I don't think it's defined in
this document, and I'm a little unsure because, even when using
singular, someone might read "stream" and think of "one stream out
of several, in a multi-streaming protocol". Maybe this is
nit-picking, but if you agree, I would prefer to replace "stream"
with "data stream", or having a definition of "stream" and
capitalizing it (but then the definition would have to appear
before the first use of this term...)

Next paragraph: double "provide" in: "Providing a message-based
abstraction provides many benefits, such as:" - I suggest to
replace the second with "has".

In the following item list, I would remove the third item: "the
ability to manage dependencies between messages, ..."
While it is true that a message-based abstraction enables this, a
reader of this document might get the impression that the TAPS
system defined in the interface draft offers this specific
functionality. It really doesn't, it would still have to be
implemented on top of it. For this reason, this item strikes me as
a bit misleading, and I think it should be removed.

Section 3, paragraph 2: "it can provide access to multiple sets of
protocols and protocol features" - remove "sets of", this adds an
unnecessary level of indirection here. I guess the transport
property profiles in interface, section B.2 would be such sets,
but still...

Last paragraph before section 3.2: "Applications using a Transport
Services system interface are REQUIRED to be robust to the
automated selection provided by the system." - why say "system
interface" here all of a sudden? This gives an impression as i

Re: [Taps] Artart early review of draft-ietf-taps-arch-11

[Gorry Fairhurst]

On 17/09/2021 21:55, Robert Sparks via Datatracker wrote:

Reviewer: Robert Sparks
Review result: Not Ready

This is an art-art early review of draft-ietf-taps-architecture

My first observation and request is that the group rethink the separation of
the architecture and interface documents. It is a warning-sign that the
interface document is a normative reference for the architecture document. As
the documents are currently constructed, a new reader cannot grasp the
architecture without inferring some of it through reading the interface.

Consider reformulating the architecture document as an overview - introduce
principles, concepts, and terminology, but don't attempt to be normative.
(There are signs that this may already be, or have been, a path the document
was being pushed towards). If nothing else, rename it, and acknowledge that the
actual architecture is specified using the interface definition.

Note that the first sentence of the Overview in the interface document also
highlights the current structural problem.

In this and the interface document, there is an inconsistent use of
capitalization to try to make Very Important Concepts visually distinctive.
Please reconsider this mechanic. If you keep it, use it consistently.

The document currently says (just before section 3.1) "The rest of this
document describes the architecture non-normatively", but then goes on to use a
bunch of 2119/8174 language (much of which really shouldn't be - please try
eliminating all of them).

Describe what you mean by racing earlier in the document - the use in the
Introduction is bare.

Describe what you mean by caching and why you might want to isolate sessions
earlier.

Describe what you mean by cloning earlier.

Consider an explicit discussion of multicast/anycast considerations in _this_
document.

The last bullet in the Overview is out of place - the others are an overview of
the document, but this one is a description of a concept.

In section 2.1 "its call to read will not complete immediately" is easy to
misread. The call to read does in fact return immediately. Any read data is
returned asyncronously. Please rework this sentence.

Make it clearer in 3.1 that you are introducing a concept named Properties. A
sentence that starts "Properties are" would really help.

In 3.1 consider "It is important for applications using a Transport Services
system to be robust to the" instead of using REQUIRED.

At 3.2, if this were a requirements document for the Transport Services system,
the SHOULD in the first paragraph might make sense. But if its an architecture
document, or better, an overview and introduction. It would be better to simply
say "is" rather than SHOULD. (And in a requirements document, I would argue
that this SHOULD should be a MUST).

In 3.3, you are talking about racing before you've described what it is. At the
point where you note that racing should only happen over stacks with identical
security properties, note when doing so might introduce privacy issues and what
can be done about them.

The big paragraph that is the first bullet of section 4.1.2 doesn't read well.
Pleas consider restructuring it, and simplifying the sentences as much as
possible.

At 4.1.7, be clearer than "without cleaning up state".

I added this as a set of issues in github, where we can also discuss 
whether/how to resolve these:


https://github.com/ietf-tapswg/api-drafts/issues

Gorry

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

Re: [Taps] W3C Web & Networks Interest Group

[Gorry Fairhurst]

On 18/05/2021 22:05, Martin Duke wrote:
This seems TAPS-ish: 
https://www.w3.org/2021/03/proposed-web-networks-charter.html 



I am not a W3C person, but do want to do a liaison statement about this?

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


This to me, seems like something that the IETF should coordinate with, 
or at least note sthat TAPS exists - TAPS Chairs, what do you think?


Gorry

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

Re: [Taps] WGLC for draft-ietf-taps-interface (to conclude 26-Apr-2021)

[Gorry Fairhurst]

On 11/04/2021 15:13, Aaron Falk wrote:


Working group last call for the API draft starts now. Please review 
the draft and send comments to the list (including ‘ready to publish’ 
affirmations) or post issues/PRs to github 
. Thanks to the authors, 
editors, and reviewers who’ve helped bring the draft to this point!


Forwarded message:

From: IETF Secretariat ietf-secretariat-re...@ietf.org

To: draft-ietf-taps-interf...@ietf.org
, taps-cha...@ietf.org

Subject: IETF WG state changed for draft-ietf-taps-interface
Date: Sun, 11 Apr 2021 07:05:50 -0700

The IETF WG state of draft-ietf-taps-interface has been changed to
"In WG
Last Call" from "WG Document" by Aaron Falk:

https://datatracker.ietf.org/doc/draft-ietf-taps-interface/



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


I've just read this carefully, and it seems nearly ready to me.

I did notice a few issues, now in github:

Some of which relate to text from text I originally proposed (sorry):

No Segmentation  #782
More thoughts on network Fragmentation  #781
To me, Safely Replayable text seems unclear ( 7.1.3.4.)  #780

UDP-Lite and Zero UDP Checksum (sect 6.1.1 and 7.1.3.6)    #776

Editorial:

Priority property "represents a hierarchy of priorities"?   #779
Update ref to dplpmtud  #778
Editorial: is Constant-Rate Streaming a path characteristic or appl 
traffic?  #777

There could be more definitions@ API #775
What is "entangled"?  #774
Editorial API NiT #773
Is Appendix A actually implementation?  #772

Gorry


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

Re: [Taps] [Editorial Errata Reported] RFC8303 (6373)

[Gorry Fairhurst]

*This seems like a typo that could be corrected, and I suggest the WG 
"Hold for Document Update", to correct future versions of the document 
when it is revised.


Gorry


*
**On 29/12/2020 08:58, RFC Errata System wrote:

The following errata report has been submitted for RFC8303,
"On the Usage of Transport Features Provided by IETF Transport Protocols".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6373

--
Type: Editorial
Reported by: Nikolai Malykh 

Section: 4.1

Original Text
-
o  SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

   Pass 1 primitive/event: 'Set_TTL' and 'Set_IPV6_Unicast_Hops'

   Parameters: IPv4 TTL value or IPv6 Hop Count value

   Comments: this allows an application to change the IPv4 TTL of
   IPv6 Hop Count value for outgoing UDP(-Lite) datagrams.



Corrected Text
--
o  SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):

   Pass 1 primitive/event: 'Set_TTL' and 'Set_IPV6_Unicast_Hops'

   Parameters: IPv4 TTL value or IPv6 Hop Count value

   Comments: this allows an application to change the IPv4 TTL or
   IPv6 Hop Count value for outgoing UDP(-Lite) datagrams.



Notes
-
typo: of instead or

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8303 (draft-ietf-taps-transports-usage-09)
--
Title   : On the Usage of Transport Features Provided by IETF 
Transport Protocols
Publication Date: February 2018
Author(s)   : M. Welzl, M. Tuexen, N. Khademi
Category: INFORMATIONAL
Source  : Transport Services
Area: Transport
Stream  : IETF
Verifying Party : IESG

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



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

Re: [Taps] Should TAPS meet during IETF-108?

[Gorry Fairhurst]

I'm OK  during the weeek or to skip the next interim, as long as we keep 
a couple of weeks clear either side of the IETF "meeting week:, so I 
don't end up with the weeks of IETF meetings that happended last time.


Gorry

On 26/05/2020 15:42, Kyle Rose wrote:
Agreed 100%. Leslie and I are also taking the approach for MOPS of an 
interim in lieu of trying to cram our remote meeting into the official 
single week for no good reason I can tell. We can schedule the meeting 
for when it's convenient for participants, and probably also make it 
easier for new folks with jobs to clear their schedules for an hour 
here or there rather than an entire week at once without the travel 
excuse.



On Tue, May 26, 2020 at 10:17 AM Aaron Falk > wrote:


Dear TAPS working group & ADs,

Scheduling has begun for the online IETF-108 meeting in July.
Should we request a meeting slot for IETF week? Frankly, I can’t
think of a good reason to do so. We’ve been making good progress
with ~monthly Webex sessions and my hope is to continue them.
Trying to schedule a meeting during IETF week will only reduce
availability of participants. Thoughts?

--aaron

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


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

Re: [Taps] Intdir telechat review of draft-ietf-taps-transport-security-11

[Gorry Fairhurst]

I think GRE (the one I know more) should be mentioned as existing somehow.

 even if the WG doesn't want to add an analysis of GRE!

A suggested starting text blob proposal for GRE could be:

Generic Routing Encapsulation [RFC2784] specifies a protocol for encapsulation 
of an arbitrary protocol over another arbitrary network layer protocol.  GRE 
tunnels do not by default provide security features. [RFC2890] describes 
enhancements by which two fields, Key and Sequence Number, can be optionally 
carried in the GRE Header to implement security functions. [RFC8086] specifies 
a method of encapsulating network protocol
packets using GRE in UDP. GRE can be used in combination with IPsec (see 
RFC2890).

Gorry

On 03/04/2020 13:10, Brian Haberman via Datatracker wrote:

Reviewer: Brian Haberman
Review result: Ready with Issues

This document is a survey of network security protocols and their interaction
with transport and application protocols. It is clearly written and easy to
read. I have a minor comment on the contents of this draft.

It is not abundantly clear what the criteria was for selecting the subset of
security protocols included in this draft. Some notable omissions include SSH,
L2TP, and GRE. These seem like interesting omissions given their popularity in
a number of deployment scenarios. Not a showstopper in my opinion, but
interesting to note.


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

Re: [Taps] Kyle Rose's review of the API draft

[Gorry Fairhurst]

See below.

On 03/04/2020 11:20, Michael Welzl wrote:

Hi,


On Apr 2, 2020, at 10:42 PM, Kyle Rose <mailto:kr...@krose.org>> wrote:


On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <mailto:mich...@ifi.uio.no>> wrote:


Hi,

I sifted through the review now, trying to address some easy
things, removing some more things that were already addressed,
creating issues for things that require some discussion… as a
result, we now have new PR #515, issues #520 - #526, and here is
one item thatI’d like to check with Kyle via this email:

5.2. Specifying Transport Properties

* Using the same enum (Require(d[sic])/Avoid/Ignore) for the
queried output of selected properties seems like a shortcut that
will lead to some confusion.

MW: I agree;  partially addressed: s/Required/Require wherever
it's a Preference level.

Kyle: FWIW, my objection to the other issue (using a normative
term as an indication of what was chosen) isn't that it's
underspecified, only that it's confusing. I put it roughly in the
same category as specifying -1 as an error indicator in an
abstract API. Is the idea that the output parameters could be fed
into the protocol selection logic for a subsequent connection to
select the same protocol? Is that useful?

Philipp Tiesel: We had text saying that these should turn into
Boolean when queried and should reflect whether the protocol
stack chosen provides the feature. I will have to double-check
whether this text is still in the description of the preference type.

MW: I found this text: "Querying a Selection Property after
establishment yields the value Require for properties of the
selected protocol and path, Avoid for properties avoided during
selection, and Ignore for all other properties."  - this seems ok
to me. Kyle?


I don't have a strong opinion about it. I just find it potentially 
confusing. Just in case, the alternative I had in mind was having an 
output enum something like { Selected, Avoided, Ignored } independent 
of the input type. As long as you understand this and are still okay 
with the interface you've chosen, that is fine by me.


I got it now, and I think your proposal is much better. I’ll do this 
in a PR.



If you go with the existing approach, I wonder if "Avoid" should be 
"Prohibit", analogous to "Require" for selected properties. 
(Similarly, maybe the opposite of "Selected" is "Prohibited" in my 
alternative approach.)


    11.1.10. Capacity Profile

* Very little of this section is about capacity. Traffic Profile?

Gorry Fairhurst:
> I don't much like Traffic Profile - to a traffic profile
specifies the characteristics of the traffic the sender is
transmitting, not the treatment that traffic expects from the
network service.


I'm trying to think of "capacity" as "path and protocol selection and 
network treatment", but it's just not clicking. Maybe there's a term 
of art definition of "capacity" I'm just not familiar with. I buy 
"capacity" as "network treatment", but path selection and protocol 
selection are both properties of the traffic as defined by the 
endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, 
not something I feel especially strongly about.)


I also don’t have a strong opinion about this, but I’ll leave it for 
Gorry to answer.




To me:

Traffic profile makes me think of TSpec, MF-Classifier, etc. Something 
that I can define within a network device that will decide what 
forwarding behaviour I see, and how I may police to this. in DS, this 
could be defined as "A traffic profile specifies the temporal properties 
of a traffic stream selected by a classifier. It provides rules for 
determining whether a particular packet is in-profile or 
out-of-profile." [RFC2475]. To me this isn't that?


Capacity is about how fast a sender can currently send along a path. My 
expectations for accessing capacity might be related to the treatement I 
tell the network that I wish to receive, such as the DSCP that is set. 
However, this isn't a capacity specification, and a capacity profile is 
just about OK to me - but not perfect, because the description doesn't 
"profile" capacity.


I'd be OK with a range of words here - and not OK with some others.

Other possibilities could be:

"Network Service"

"Network Service Marking"

Or even more-specific:

"DS Marking"

I would be very happy to think upon others - but the keyword space is 
limited and we should avoid overlap with terms that mean something else :-).


Gorry



5.2.11. Provisioning Domain Instance or Type

* What about ordering of similar interfaces? I have a 2-SIM
cellphone 

Re: [Taps] [ietf-tapswg/api-drafts] Reliable Data Transfer (Message) default - from Kyle Rose's review (#520)

[Gorry Fairhurst]

We seem to need to decide what "Reliable Data Transfer" means to an 
Application.


My point. expanding here a little, is:

TAPS has to by default do something if the app doesn't say what it 
wants. So this is really about the default service chosen by TAPS.  A 
safe assumption is that an app not designed for reordering, loss, 
duplication etc  will receive the default service, that's why I think 
this should be "Reliable Data Transfer".


Apps that CAN handle all of these need to tell the TAPS Interface that 
they do not need a "Reliable Data Transfer". If the app does not do 
this, and happens to exist on a stack that only supports datagrams, then 
it would not be able to connect.


Gorry

On 02/04/2020 13:32, mwelzl wrote:


List discussion:

*Kyle:*

7.4.7. Reliable Data Transfer (Message)

  * The default isn't "true", it's whatever the underlying
connection had, right?

*@philsbln *:

Ack

*@mwelzl *:

I agree too, but doesn’t this warrant some more discussion?
I think our defaults all translate into things that can work in
some way when TCP is used - with “Reliable Data Transfer” being an
exception, as it just can’t work in a UDP-only system. Are there
others? I think I’ll open an issue for this one.

*@gorryfair *:

I don't agree at all - To me this was just the default behaviour
of the API.

I think the default needs to be "reliable" and an app will have to
over-ride that to get datagram/unreliable operation. That doesn't
mean if you have only UDP (for instance) that you can't offer
TAPS, to me it simply means you always need to say that the app
wants this service.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub 
, or unsubscribe 
.


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

Re: [Taps] April interim: - My promised review of normative arch language (derived from github).

[Gorry Fairhurst]

On 25/03/2020 16:30, Mirja Kuehlewind wrote:

Thanks, Gorry, for this! I support the idea of having one section with 
normative requirement at the beginning. Would be nice if someone could put this 
in a PR. I guess we need to add at least one more requirement on use of 
security protocols at least.


Sure - have you an idea for a "placeholder bullet" we can add to my list 
below... so we don't loose the thought...


Gorry


Mirja


On 25.03.20, 17:03, "Taps on behalf of Gorry Fairhurst"  wrote:

 As promised,
 
 I did a review of the arch draft and the PR that was recently done.

 There were comments that requested to remove some normative language
 that has been implemented in the current draft - where my review agreed,
 I have not commented further below. However, the latest revision, also
 did not retain the discussion of what I suggested should be normative. I
 have worked through the various comments in github and summarise them
 here (since these comments are now burried in the git, see 502 et al).
 
 So here goes:
 
 Overall review: I think we need to keep the normative language for the

 key features that differentiate the API. I'd really like to use
 REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not
 protocol operation requirements, but are implementation requirements to
 conform. This includes requirements based on Minset - where the WG
 dervied this API: This is after all why the WG worked on Minset as the
 basis of the API.
 
 
 
 The following are key requirements, that define the TAPS architecture:
 
 * It is RECOMMENDED that functionality that is common across multiple

 transport protocols is made accessible through a unified set of TAPS
 interface calls. As a baseline, a Transport Services API is
 RECOMMENDED/REQUIRED to allow access to the minimal set of features
 offered by transport protocols {{?I-D.ietf-taps-minset}}.
 
 * TAPS automates the selection of protocols and features, based on a set

 of Properties supplied through the TAPS interface. It is RECOMMENDED
 that a TAPS system offers Properties that are common to multiple
 transport protocols. Specifying common Properties enables a system to
 appropriately select between protocols that offer equivalent features.
 This design permits evolution of the transport protocols and functions
 without affecting the programs using the system.
 
 * Applications using the TAPS API are REQUIRED to be robust to the

 automated selection provided by TAPS, including the possibility to
 express requirements and preferences that constrain the choices that can
 be made by the system.  In normal use, TAPS Systems are RECOMMENDED to
 be designed so that all selection decisions result in consistent choices
 for the same network conditions when they have the same set of
 preferences. This is intended to provide predictable outcomes to the
 application using the transport service.
 
 * Applications using TAPS MAY explicitly require or prevent the use of

 specific transport features (and transport protocols) using the
 "REQUIRED" and "PROHIBIT" preferences. This allows an application to
 constrain the set of protocols and features that will be selected for
 the transport service. It is RECOMMENDED that the default usage by
 applications does not unecessarily restrict this selection, so that the
 system can make informed choices (e.g., based on the availability of
 interfaces or set of transport protocols available for the specified
 remote endpoint).
 
 
 ---
 
 After thought, here is my specific poposal of what to do next:
 
 (a) I suggest we group all the requirements on architecture as short one

 or two sentence blocks (preferably as a bullet or definition list)
 collected into a single subsection, so they are easy to find and read
 and we say that these are the key architectural requirements. I suggest
 we insert this new requirements text either their own section, or in
 section 1.3 (although I am open to other places where we can call-out
 the architectural requirements).
 
 (b) We need to decide if these are architectural requirements and if

 there are more or less in total. I am of course open to more refined
 wording:-).
 
 (c) We could also explicitly say there are additional requirements in

 racing  in section XX.
 
 (d) If this plan seems appropriate, I would then suggest to use lower

 case within the remainder of document (we could refer to the
 requirements subsection, if we thought necessary).
 
 Thoughts please, but review now completed!
 
 Gorry
 
 
 ---
 
 
 Additional Language NiT:
 
 I thi

Re: [Taps] April interim: - My promised review of normative arch language (derived from github).

[Gorry Fairhurst]

As promised,

I did a review of the arch draft and the PR that was recently done. 
There were comments that requested to remove some normative language 
that has been implemented in the current draft - where my review agreed, 
I have not commented further below. However, the latest revision, also 
did not retain the discussion of what I suggested should be normative. I 
have worked through the various comments in github and summarise them 
here (since these comments are now burried in the git, see 502 et al).


So here goes:

Overall review: I think we need to keep the normative language for the 
key features that differentiate the API. I'd really like to use 
REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not 
protocol operation requirements, but are implementation requirements to 
conform. This includes requirements based on Minset - where the WG 
dervied this API: This is after all why the WG worked on Minset as the 
basis of the API.




The following are key requirements, that define the TAPS architecture:

* It is RECOMMENDED that functionality that is common across multiple 
transport protocols is made accessible through a unified set of TAPS 
interface calls. As a baseline, a Transport Services API is 
RECOMMENDED/REQUIRED to allow access to the minimal set of features 
offered by transport protocols {{?I-D.ietf-taps-minset}}.


* TAPS automates the selection of protocols and features, based on a set 
of Properties supplied through the TAPS interface. It is RECOMMENDED 
that a TAPS system offers Properties that are common to multiple 
transport protocols. Specifying common Properties enables a system to 
appropriately select between protocols that offer equivalent features. 
This design permits evolution of the transport protocols and functions 
without affecting the programs using the system.


* Applications using the TAPS API are REQUIRED to be robust to the 
automated selection provided by TAPS, including the possibility to 
express requirements and preferences that constrain the choices that can 
be made by the system.  In normal use, TAPS Systems are RECOMMENDED to 
be designed so that all selection decisions result in consistent choices 
for the same network conditions when they have the same set of 
preferences. This is intended to provide predictable outcomes to the 
application using the transport service.


* Applications using TAPS MAY explicitly require or prevent the use of 
specific transport features (and transport protocols) using the 
"REQUIRED" and "PROHIBIT" preferences. This allows an application to 
constrain the set of protocols and features that will be selected for 
the transport service. It is RECOMMENDED that the default usage by 
applications does not unecessarily restrict this selection, so that the 
system can make informed choices (e.g., based on the availability of 
interfaces or set of transport protocols available for the specified 
remote endpoint).



---

After thought, here is my specific poposal of what to do next:

(a) I suggest we group all the requirements on architecture as short one 
or two sentence blocks (preferably as a bullet or definition list) 
collected into a single subsection, so they are easy to find and read 
and we say that these are the key architectural requirements. I suggest 
we insert this new requirements text either their own section, or in 
section 1.3 (although I am open to other places where we can call-out 
the architectural requirements).


(b) We need to decide if these are architectural requirements and if 
there are more or less in total. I am of course open to more refined 
wording:-).


(c) We could also explicitly say there are additional requirements in 
racing  in section XX.


(d) If this plan seems appropriate, I would then suggest to use lower 
case within the remainder of document (we could refer to the 
requirements subsection, if we thought necessary).


Thoughts please, but review now completed!

Gorry


---


Additional Language NiT:

I think the word /assumes/ is not a good choice of word.

OLD:

and it assumes an implementation that can use multiple IP addresses, 
multiple protocols, multiple paths, and provide multiple application streams


NEW:

and it can provide benefit when an implementation can use multiple IP 
addresses, multiple protocols, multiple paths, and provide multiple 
application streams.


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

[Taps] Review of Arch wrt to normative requirements on the architecture

[Gorry Fairhurst]

I have now reveiwed the Arch document for normative language, as promised.


After the review, I would still be in favour of using RFC2119 language 
to describe what is required architecturally to be a TAPS system. In my 
review, I agree the number of requirements is now reduced.


I really do wonder if we could (please) group all these requirements on 
architecture into a single subsection, so they are easy to read - and we 
can they say that these are the architectural requirements, explcitly 
refererence those in section XX relating to racing. I suggest we insert 
this requirements text either as short text blocks in their own section, 
or simply a set of bullets in section 1.3 (although I am open to other 
places where we can call-out the architectural requirements).


Perhaps we should also check we still have captured something along the 
lines of:


"The System should permit evolution of the system without affecting 
programs using it. In normal use, TAPS systems are RECOMMENDED to result 
in consistent selection for the same network conditions when they have 
the same set of preferences, but applications using the TAPS API are 
REQUIRED to be robust to the automated selection, including the 
possibility to express requirements that constrain the choices that can 
be made by the system." And possibly add "Applications using TAPS can 
explicitly require or prevent the use of specific transport features 
(and transport protocols) using the "REQUIRED" and "PROHIBIT"..." or 
something like that.


If this seems appropriate to add a section on overall requirements, I 
would then suggest to use lower case within the document and simply 
refer to this subsection, where necessary to get the RFC2119 sentences.


I made specific comments in pull request, #502:

https://github.com/ietf-tapswg/api-drafts/pull/502


--- Comments or imrpovements welcome!

Gorry

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

Re: [Taps] draft-ietf-taps-interface-05 review

[Gorry Fairhurst]

See in-line


On 05/03/2020 07:30, Michael Welzl wrote:

Hi,

A few comments in line:

On Mar 4, 2020, at 5:51 PM, Philipp S. Tiesel > wrote:


Hi,

Some of the remaining issues had already been discussed, but either 
did not lead to text or the text was lost. Let me comment on these 
issues:


On 4. Mar 2020, at 15:38, Michael Welzl > wrote:


REMAINING UNADDRESSED COMMENTS FROM KYLE ROSE:


2. Terminology and Notation

* The notation "Sender -> Event" says nothing about who receives the 
event. Is it just assumed to be the application in the context of 
the particular event (e.g., a thread processing a particular 
connection)?


MW: We have the following statement in this section: "Events could 
be implemented via event queues, handler functions or classes, 
communicating sequential processes, or other asynchronous calling 
conventions."
I wonder why this isn't enough information? E.g., if handlers are 
used, then the recipient of the event is a pre-registered handler - 
and handlers must therefore be registered before events can occur; 
this function isn't visible in the API because this is platform- and 
language-specific.



4.2.1. Transport Property Names

* The use of dashes in property names means they will necessarily 
look different in almost every widely-used language, in which dash 
is an operator.


The solution for this issue was to allow implementations to change 
the property names in consistent ways, e.g., by replacing the dashes 
with underscores or removing them and use CamelCasing.

The text was removed as over-specific.


I remember that. However, the proposal here would be to just replace 
the property names instead of adding new text.

Let me propose: can we just update them all to CamelCasing?


I like this idea.


* If we're not currently asking IANA to create a registry of 
property names or namespaces, should we provide a recommendation 
that such symbols not listed explcitly in this document be prefixed 
with some experimental identifier?


The IANA registry question was explicitly postponed, be maybe we 
should re-iterate it now.
The idea of having an „x“ namespace was rejected in fear we end up 
with quasi-standard properties that have an x prefix then.


5.2. Specifying Transport Properties

* There are a lot of choices being made about how users will want to 
prioritize transport protocol selection. How confident are we that, 
for instance, path selection should take priority over protocol 
selection? I think that's right, but I wonder if it might not make 
more sense to have two interfaces: one that provides a purely 
numeric priority ordering of preferences, and one (based on the 
existing 5-level preferences) that maps into it.


We had a lengthy discussion about this and rejected it as too complex 
and limiting for the implementation.


Right. Maybe we should just remove this item from this list.

* Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried 
output of selected properties seems like a shortcut that will lead 
to some confusion.


We had text saying that these should turn into Boolean when queried 
and should reflect whether the protocol stack chosen provides the 
feature. I will have to double-check whether this text is still in 
the description of the preference type.


MW: I agree;  partially addressed: s/Required/Require wherever it's 
a Preference level.



5.2.5. Use 0-RTT Session Establishment with an Idempotent Message

* I'll repeat the same statement I made at the mic a few years ago: 
idempotency != replay-safe. DELETE is idempotent, but not safe for 
replay because someone might have done a PUT or POST in the meantime.


MW: I remember you saying this, sorry that we haven't addressed it 
yet! I didn't understand - is your concern about replaying that a 
Message may arrive later, i.e. as Message X, Messages Y and Z in 
between, then Message X again?  => if so, are you saying that this 
could happen with TFO or QUIC?  (I didn't think so)



5.2.10. Interface Instance or Type

* These type symbols really deserve an actual registry, or at least 
the start of one. Otherwise, we are likely to end up with a mess.


There is already one, but that one was not useful for our matters.


5.2.11. Provisioning Domain Instance or Type

* What about ordering of similar interfaces? I have a 2-SIM 
cellphone with wifi.


Each cellular provider will have a unique PVD.


5.3.2. Connection Establishment Callbacks

* What constitutes trust verification prior to the handshake?

7.3.1. Sent

* It seems like an abstract API would be helpful for the reference 
to the Message to which a Sent event applies: this seems like 
something many, many applications would need to do. With callbacks, 
the application can always curry in a reference to the original 
message (that's what my event system from ~2001 did), so maybe that 
should be the recommendation and the message reference removed...? I 
don't have a stron

Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020)

[Gorry Fairhurst]

I have some minor editorial comments from a careful reading (see below).

Best wishses,

Gorry

(P.S. I'm an editor for this document and I do think the I-D is ready to 
proceed).


---

In Section 2:
/The Socket API/
The text uses /sockets/, but previously the text in 2.1 talks about the 
Socket API.
I didn’t see a problem here while we were working on the spec, but I 
think it world be better is section 2 explicating introduced the word 
/sockets/ and defined the Socket API as a definition of the sockets 
method. At least /sockets/ needs to be explained before it is used in 
Sections 2.1 2.2, 2.3, etc.

---
In Section 3.2
/handover or failover for a Connection/
- should this use a lower case letter ‘c’ for connection. This seems to 
be before the document defines a specific meaning for a TAPS Connection.

---
In Title of Figure 4:
Title: /The lifetime of a connection/
- I think this does warrant a capital letter ‘C’ for connection? or 
alternatively a re-wording to say something abstract, like: /The 
lifetime of a connection in the TAPS archicture/

---
In Section 4.1.1.
/A Preconnection object is a representation of a
potential connection./
- Does this warrant a capital letter ‘C’ for connection? (if not then I 
think it should say a /connection to be established? or similar).

---
In Section 4.1.2.
/ requirements around the Maximum Transmission Unit (MTU) or path
  MTU (PMTU),/
- The example is OK, but the words are not really correct. I don’t think 
general purpose apps need to know about the local MTU ever, they may 
care bout the PMTU - but really they care about the maximum packet size they
can send along a path. That’s an application-layer quantity, and isn’t 
related to the ultimate size of packet emitted by an interface. In 
writing the DPLPMTUD spec we have ben encouraged to make this difference 
more explicit, and I think TAPS should also not confuse interface 
limits, network limits and application limits. Packet Size anyway have 
little bearing on transports that perform message segmentation and are 
hugely important when they don’t.

My suggested text would be:
/ requirements around the largest packet that can be sent,/
---
In Section 4.2:
/ A single stack can be simple (a single transport
  protocol instance over IP), or complex (multiple application
  protocol streams going through a single security and transport
  protocol, over IP; or, a multi-path transport protocol over
  multiple transport sub-flows).
/
- This has become quite a long and complex sentence! I’d really prefer 
to use numbers or some way to highlight the two concepts of simple and 
complex. I don’t know what is best. Another possibility could be to make 
it even longer, but more clear:

/ A single stack can be either simple (a single transport
  protocol instance over IP), or it can be complex (multiple 
application

  protocol streams going through a single security and transport
  protocol, over IP; or, a multi-path transport protocol over
  multiple transport sub-flows).
---
In Section 4.2: Candidate Path:
The clause:
/, of which there can be several./
appears in bullet two for Candidate Protocol Stack:, but not for 
Candidate Path. I expect there be multiple candidate paths also in this 
case, can we add this?

---
In Section 4.2: Candidate Protocol Selection
/represents the act of choosing one or more sets of protocol stacks/
- why not capitilised /Protocol Stacks/?
---
In Section 4.2: Remote Endpoint Racing:
/that differ based on the specific
  representation of the Remote Endpoint, such as IP addresses
  resolved from a DNS hostname./
- do we have use of singular/plural correct here, or should this be more 
like:

/that differ based on the specific
  representation of the Remote Endpoint, such as a
  specific IP address that was
  resolved from a DNS hostname./
---
In Section 4.2.3: Protocol Stack Equivalence
/The Transport Services architecture defines a mechanism that allows
   applications to easily use different network paths and Protocol
   Stacks./
- Is this /use/ , i.e. are we talking about how to use these - which looks
like just multipath, or is this better as:
/The Transport Services architecture defines a mechanism that allows
   applications to easily communicate when there can be different 
network paths and Protocol Stacks./

---
In Section 4.2.4:
/   The interface to specify these groups MAY expose fine-grained tuning
   for which properties and cached state is allowed to be shared with
   other Connections. /
- I think it would be nice if this sentence actually was self-contained, 
since it contains a RFC2119 keyword. Perhaps we could say:
/   The interface to specify a Connection Group MAY expose fine-grained 
tuning for which properties and cached state is allowed to be shared 
with   other Connections. /

---


On 07/01/2020 15:50, Aaron Falk wrote:


This is notice to open working group last call for “An Architecture 
for Transport Servic

Re: [Taps] On Profiles for TAPS Preconnections

[Gorry Fairhurst]

Hi all, see below - how near are we to agreement?

On 23/07/2019, 14:21, Brian Trammell (IETF) wrote:

hi Tommy, all,


On 22 Jul 2019, at 19:15, Tommy Pauly  wrote:




On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel  wrote:

Hi,


On 22. Jul 2019, at 15:09, Tommy Pauly  
wrote:

An issue we discussed today in the TAPS meeting was whether or not we should add a concept of 
"profiles" to the Transport Services APIs. An example of a profile is a "reliable, secure, 
in-order stream"; or "unreliable datagrams". Another way to think of these profiles are as 
convenient ways to initialize common parameters.

One option is described in this PR: 
https://github.com/ietf-tapswg/api-drafts/pull/328

To help discern the working group's position, I'll try to distill the 
high-level options here:

1. Add Profiles as a top-level API document concept that modifies how transport 
properties and/or preconnections are created. (This is PR #328.)
2. Mention in the API document that specific API implementations may expose 
conveniences and profiles (presumably as a way to initialize preconnections), 
but do not modify the API or specify an abstract symbol for profiles.
3. Do not mention profiles at all in the API document, but mention something in 
the implementation document.

I am definitely in favour of option 1. Our implementation experience with 
PyTAPS showed that setting all transport properties necessary to get “UDP like 
service” becomes tedious otherwise.
I fear not including them in the examples and the core API will result in many 
developers rejecting TAPS as too complex to use.
The profiles provide a useful convenience to applications (just like the the 
shortcuts properties.prefer(property) instead of properties.add(property, 
prefer)).

In addition, profiles allow us to be less conservative in how we choose the 
defaults for transport properties, i.e., we don’t need the TAPS defaults to be 
TCP compatible as long as the reliable-in-order-stream profile is.

Speaking not as the person asking the question, but as an individual in the 
group:

I'm pretty strongly against option (1), and prefer (2). I think we should 
specify that convenience functions can exist, but I think changing the one 
initialization function of the transport properties to take a profile is not 
the right move for the API. Everything can be achieved by making the API for a 
convenience profile be a layer on top of the existing API.

+1, for the same reasons.
I'm fairly striongly against (3). Profiles are really important as a 
concept and I'd really encourage the group to write this.


Some additional motivation is that it can very significantly impact the 
way the TAPS system is presented to the user. It can help allow 
applications to set many TAPS parameters, providing additional info to 
the selection (racing) without the pain of having to understand what 
each parameter should be set to. That's a big simplification. For 
example a low-rate transactional app could eplicitly need datagram to 
make choices for low latency using one profile - another app that wishes 
to optimise for throughput could start by setting a different profile.

Specifically, these are the differences:

(1) Exposes an API in which you always pass a profile (or an explicit nil) to a 
TransportProperties object; but the TransportProperties *also* lets you set 
each of the individual properties after that.
The API options win: Apps can choose a profile, and they can - maybe 
should be encouraged to - over-ride anything that is important to them.

I really like the idea of being able to pull a profile off the shelf and then 
tweak it.

It does seem to me that the right model here is "profiles as convenience 
constructors or copyable constants" -- that model is pretty reasonably implementable 
as an add-on, without

(That's separate from the question of whether profiles are a "mandatory" 
feature in taps-interface, a suggested feature in an appendix, or something that exists 
in a different document).

Cheers,

Brian
+1 if you'd like to have (sample) profile descriptions in an informative 
appendix, that would seem like a way to achieve that.

(2) Allows implementations to expose an API call to deliver a 
TransportProperties that's set up based on a profile, but that isn't the 
fundamental constructor. It is implemented by creating a TransportProperties 
(TransportProperties()) and then setting the properties internally.

Thanks,
Tommy
At the start of TAPS, I thought of profiles as the same as other 
parameters (i.e. they are inputs to the selection algorithm, that are 
less signficant than apps-supplied params, and more significant that the 
system default).


I'd prefer we call this out explicitly in the documents.

Gorry


AVE!
  Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/


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

_

Re: [Taps] How to handle Protocol stacks that are not equivalent

[Gorry Fairhurst]

On 23/07/2019, 10:31, Tommy Pauly wrote:

My initial impression here is that any protocol stacks that provide the same 
transport services, and thus can be raced as candidates, need to be equivalent. 
It ends up being a bit tautological. The description in the architecture 
explains what combinations are allowed based on preference—if you don't require 
reliability, then a UDP protocol stack is equivalent to a message protocol over 
TCP. If you do require reliability, then those aren't equivalent.

Thanks,
Tommy

That makes sense to me.

Gorry

On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel  wrote:

Hi,

as time did not permit to discuss all open issues in the session today, I’ll 
take them to the list as proposed.
This issue is based on Github issue #305: 
https://github.com/ietf-tapswg/api-drafts/issues/305

Following the architecture draft, only protocol stacks that are equivalent can 
be safely raced. What should happen if selection properties result in a 
candidate set that includes protocol stacks that are not intuitively equivalent?


Resolution Proposals:

a) Define Protocol Stack Equivalence more rigorously. A possible way to do this 
would be to say two stacks are equivalent with respect to the applications’ 
requirements if both fulfil all require properties specified by the 
applications and do not violate any of the prohibit properties.

b) Generate some kind of Error Event for configurations with unlike protocol stack 
candidates. (May need a definition of "unlike”).

c) Do nothing and close the issue.


AVE!
   Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

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

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


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

Re: [Taps] updated agenda - Re: Transport Services (taps) WG Virtual Meeting: 2019-05-08

[Gorry Fairhurst]

Could we please add some time to discuss the parameters and defaults - 
Phil has been trying to get these into shape for some time and the text 
in the iD has evolved to a place where decisions now need to be made, 
and I'd really rather this was not pushed to the end of the agenda as 
"other issues".


In API, this relates to (this may also finally touch implementation):

Default for Use 0-RTT session establishment #314
Default for Control checksum coverage #315
The recommended default and can we specify rather than recommend? #317
Section 7 default #319

Gorry

On 07/05/2019, 19:52, Aaron Falk wrote:


Collating the input from the thread. Who will lead the discussion on 
the implementation draft?


--aaron

Agenda:

 1. Framing - Tommy
  * See https://github.com/ietf-tapswg/api-drafts/pull/323
 2. Implementation draft - ??
  * See https://datatracker.ietf.org/doc/draft-ietf-taps-impl/
 3. Yang Model - Jake
  * See

https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/PyTAPS/modules/ietf-taps-api.yang
 4. ARCH & API issue scrub & assign - Brian
  * See https://github.com/ietf-tapswg/issues



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


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

Re: [Taps] WGLC for draft-ietf-taps-transport-security (ending 4/29)

[Gorry Fairhurst]

Review of draft-ietf-taps-transport-security-06.

I have read the above document as a transport person, and contributor to 
the group and think this document contains the material that was 
discussed by the working group and is very near a version that is ready 
to publish.


I have a number of comments below.

Scoping and potential use to endorse non-ietf protocols:

As a technical question to the Chairs/AD - does the document need to 
carry some caveat about non-IETF protocols being standardised outside 
the RFC-series and not making a statement on recommending or otherwise 
endorsing their use?


Abstract

I think the abstract should define “TAPS”. probably this should also be 
defined when first used also in the body of the text. Similarly protocol 
names such as: Transport Layer Security (TLS), TCP-AO, ALTs, BGP, AH, 
IKE,etc should be defined when first used, and abbreviations such as MAC 
(PRF), EAP, ALPN, Server Name Indication (SNI), DoS, PKI.


Abbreviations

“starting with TLS 1.3”
- should there be a reference here?
“NAT rebindings”
- should there be a reference to one of the BEHAVE RFCs here?

I think I-D.ietf-tls-tls13 has been published as RFC 8446

X.509 certificates are mentioned in 4.10.1, and could benefit from a 
reference.


authenticates the payload using HMAC is mentioned in 4.10.1, and could 
benefit from a reference.


In section 4.2:
“DTLS is modified from TLS to operate with the possibility of packet
loss, reordering, and duplication that may occur when operating over
UDP. “
- I think this can be used over datagram protocols, and it would be 
worth saying that and adding ane maple of: Datagram Transport Layer 
Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)

RFC 5238

Typo in reference format?:
“{{I-D.ietf-tls-dtls13}”

In Section 4.2.2:
- Could you provide a cross-reference to the section in “ See also the 
features from TLS.”


Comments on the text:

I support Aaron’s comment on the term “network security layer” - do we 
need to use the term layer here, since this is expected to be placed 
below the transport API?


In Section 4.2.3. (on Protocol Dependencies)

o DTLS relies on UDP.
- or any datagram service? (see above note on DTLS over DCCP as an 
example.), in 4.93 the text says “An unreliable transport protocol such 
as UDP.” - which could be more appropriate?


“Path MTU discovery.”
- Could we write this as “discovery of the Path MTU” to explicitly not 
say use the name of a protocol here?


In Section 4.3.1:
“The QUIC transport layer support multiple streams”
- insert “s” after “support”.
“Once TLS completes, QUIC uses the
resultant traffic secrets to for the QUIC connection to protect the
rest of the streams.”
Replace “to for” by “for”?

“Owing to middlebox ossification issues, tcpcrypt only protects the
payload portion of a TCP packet. It does not encrypt any header
information, such as the TCP sequence number.”
- I am not sure I agree with the implication here!
- Would it be OK to state this more neutrally as:
“Because of the possible presence of firewalls and other middleboxes on the
path, tcpcrypt only protects the
payload portion of a TCP packet. It does not encrypt any header
information, such as the TCP sequence number.”

Security Considerations:

Section 8 uses a RFC2119 keyword: “ Applications using Security 
Interfaces SHOULD take such

limitations into consideration when using a particular protocol
implementation.”
- I suggest replacing this by “ought to”?

Acknowledgments

NiT: “Theresa Enghardt” is an editor and an acknowledged contributor, 
suggest you remove the name from the ACK section.


References

The references have not been divided into normative and informative 
references. I am unsure/uneasy at this time if this list of references 
all need to be normative.
- In particular, some non-IETF documents are cited as normative 
references. This strikes me as difficult to justify and something that 
needs careful consideration.
- I am concerned there are normative references to quite a number of 
Internet drafts. Are these necessary - if these need to be normative 
then the WG needs to consider if this may block publication of the 
document for some time to come!
- I note that in RFC 8095 we chose to make all protocol references 
informational.


Security

This review was from a viewpoint of providing transport oversight. I did 
not review the summary table contents nor the assertions on which 
mechanisms were present in which protocols, where security expertise is 
needed.


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

Re: [Taps] To registry, or not to registry?

[Gorry Fairhurst]

For what it is worth: I think this is an attempt to standardise some 
names... and avoid many variants of the same. That may work, or it may 
fail horribly. which to me depends on the interests of TAPS developers 
in standardising cross-platform support. I think I suggested anyway if 
we go this way, that we really need to differentiate IETF-RFC entries 
from privately defined ones.


And... I for one think this can wait. I'd rather have a complete 
revision to proof read than worry about the registry


Gorry

On 05/09/2018 16:05, Brian Trammell (IETF) wrote:

Hi, all,

I'd see the contents of the appropriate sections of taps-interface (7.3 and 
12.3 in the current editor's copy at 
https://taps-api.github.io/drafts/draft-ietf-taps-interface.html) as the 
initial contents of these registries, and MTI as per the (normative) RFC 
taps-interface will become. Anything else should be added to the registry on 
either expert

As to how useful a set of names beyond those in the document will be in terms 
of reducing the confusion of users of taps-compliant APIs: eh? I'm not sure.

Metaquestion: is this a question we have to answer before publishing the 
current documents, or can we focus on getting them done, then potentially 
specify a registry in a future document (incorporating the parameters in the 
already-published taps-interface by reference)?

Cheers,

Brian


On 5 Sep 2018, at 16:31, Michael Welzl  wrote:

Hi all,

I like the idea too, but I also wonder: does this give us a risk that the whole 
system could become super-flexible, obscure and non-implementable at some point?

But maybe that’s easily solved, by stating that only the transport properties 
in RFCs are required to implement, and everything from the registry is optional…

Cheers,
Michael



On Aug 6, 2018, at 11:44 AM, Gorry Fairhurst  wrote:


I quite like the idea of trying to design a simple registry format. If it looks 
good, I'd be happy to see this go forward.

Gorry

On 24/07/2018 19:13, Aaron Falk wrote:

Caveat: I am not an expert on registries but my sense is that they are most 
useful for interoperability. I think Gorry's concern about redundancy much less 
important. And, in fact, it may take a while to figure out how to describe the 
parameters. It might be more useful to allow for variety in how these are 
defined to permit creative approaches. YMMV of course.

--aaron

On 24 Jul 2018, at 10:06, G Fairhurst wrote:

   I don't yet know for sure myself

   On the one hand: I think a registry is a great way to capture the
   "bundle" of things that we know about needing to send across the
   API. Having common keywords (names) is a way to help people (who
   wish to take this approach) from unwantingly choosing the same
   function/param with a different name. And avoids accidentally
   choosing the same key. I like these advantages. especially if I
   thought people would use the registry.

   On the other hand, as an author I am still bemused about exactly
   which list of items I think /need/ could appear in this registry.
   I know some I'd expect, there are some I would not be surprised to
   see, and some I'd expect not to see. Also this doesn't stop people
   dreaming of slight variants of functions/params because they want
   to be different or don't understand/agree with another definition,
   especially since the concrete API isn't specified by the IETF.

   There are ways we could help support different uses, which I think
   we should consider:
   * We can define "well-known" IETF keywords that start with a
   special prefix that require some IETF practice to assign;
   * we can also define "public" keywords that have no prefix and are
   first-come-first served, the easy way to get a unique entery.
   * We can allow private defintions with some different prefix that
   are not specified by IANA. (We simply preclude this format from
   the registry).

   This approach has been used in many places, a simple, but similar
   transport example is the Service Codes registry:
   https://www.iana.org/assignments/service-codes/service-codes.xhtml

   - Let's all think about whether this is a useful approach for our API?

   Gorry


   On 23/07/2018, 21:32, David Schinazi wrote:

   We had a similar discussion in the Babel WG regarding link
   types in our data model - which isn't sent over the wire.
   We landed on having an IANA registry of strings so there is
   one place to find the mapping from string to specification.
   We're planning on reserving all strings starting with an
   underscore "_" for experimental use so the registry does not
   get in anyone's way.
   Apparently IANA registries have very low overhead.
   Hope this helps.

   David

   On Jul 23, 2018, at 13:15, Tommy Pauly mailto:tpa...@apple.com>> wrote:

   Hello

Re: [Taps] Progress on address usage documents

[Gorry Fairhurst]

On 07/08/2018, 18:00, Tommy Pauly wrote:



On Aug 7, 2018, at 9:26 AM, Fernando Gont  wrote:

Hello, Gorry,

On 08/07/2018 05:26 PM, Gorry Fairhurst wrote:

To me, this topic is tricky to position, and there are still multiple
parts across the two documents.

One way could be to agree the properties of different address types on
scope and stability, devoid of API and Application-considerations -  I
at the moment don't currently understand this enough to say if this is a
new statement about the network layer or is restating what has been said
before, so to me at least this seems to need network-layer clue.  I see
there may be a network layer security concern that may drive some
considerations (seems more like that part is in
  draft-gont-taps-address-analysis)

For the most part, address types are specified, but there's not much
guidance on how to use them. Depending on the perspective, I guess one
might argue that guidance should come from internet area (6man for the
ipv6 specific case, and intarea for ipv4... or even both).


 From another POV, this sees to be related with TAPs. If you hve an api,

there's not much you will be able to do (at least in a proper way :-) ),
without appropriate guidance.




To answer the immediate question: I think this doesn't look like TAPS
should adopt that document. If this ID needs transport clue and spans
multiple transport protocols, that could be reviewed by TSVWG if this
had already strong support elsewhere?

There is a mention of an API and usage concern. I haven't worked out if
that is transport guidance,

That's mostly a problem statement: we don't have appropriate APIs to
fully leverage IPv6 addressing.


[]

Possibly there is also a need for a new API, and if that needs the IETF
to do new work, then to me that does look a lot like source address
selection in TAPS. There could be useful input here to a few paras in
the TAPS architecture. It's not clear to me that would require a new
draft though in TAPS to achieve this.

Could you please rovide a reference to the document so that I can take a
look and review?

The GitHub for the documents is:

https://github.com/taps-api/drafts

https://taps-api.github.io/drafts/draft-ietf-taps-arch.html
https://taps-api.github.io/drafts/draft-ietf-taps-interface.html
https://taps-api.github.io/drafts/draft-ietf-taps-impl.html

I imagine that we could have a *brief* mention in the architecture,
To be clear - this is what I had in mind, that we ensure we mention that 
source interface selection is something that the arch can handle - 
whether it be by properties, or the way security expectations are 
satisfied, the available PvDs etc. But nothing much.

but more importantly provide a path selection property in the Interface/API 
document, with an implementation considerations section in the Implementation 
document. Having an internet area draft to refer to from the API specification 
would be useful.

A little here also could make sense.

Gorry

Tommy

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




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

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


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

Re: [Taps] Progress on address usage documents

[Gorry Fairhurst]

To me, this topic is tricky to position, and there are still multiple 
parts across the two documents.


One way could be to agree the properties of different address types on 
scope and stability, devoid of API and Application-considerations -  I 
at the moment don't currently understand this enough to say if this is a 
new statement about the network layer or is restating what has been said 
before, so to me at least this seems to need network-layer clue.  I see 
there may be a network layer security concern that may drive some 
considerations (seems more like that part is in



 draft-gont-taps-address-analysis)

.

To answer the immediate question: I think this doesn't look like TAPS 
should adopt that document. If this ID needs transport clue and spans 
multiple transport protocols, that could be reviewed by TSVWG if this 
had already strong support elsewhere?


There is a mention of an API and usage concern. I haven't worked out if 
that is transport guidance, or whether the required mechanisms actually 
resembles PvD usage, and therefore looks more like a network-issue, (of 
course this is without a need for signalling from the network to 
identify properties).


Possibly there is also a need for a new API, and if that needs the IETF 
to do new work, then to me that does look a lot like source address 
selection in TAPS. There could be useful input here to a few paras in 
the TAPS architecture. It's not clear to me that would require a new 
draft though in TAPS to achieve this.


Gorry

On 07/08/2018, 12:59, Ole Troan wrote:

draft-gont-taps-address-usage-problem-statement says

This document analyzes the impact of a number of properties of IPv6
addresses on areas such as security and privacy, and analyzes how
IPv6 addresses are curently generated and employed by different
operating systems and applications. Finally, it provides a problem
statement by identifying and analyzing gaps that prevent systems and
applications from fully-leveraging IPv6 addressing capabilities,
setting the basis for further work that could fill those gaps.

I think the applicability of this work goes potentially far beyond TAPS as it 
applies to any application's use of IPv6 addresses. I'm a little worried that 
this wg doesn't contain sufficiently broad perspective to make recommendations. 
Indeed, I see TAPS as a consumer of this doc more than source of the 
recommendations. My opinion is that this is kind of out of scope for our wg. I 
would support another group with the right expertise to support it (maybe 6MAN 
or V6OPS). I think TAPS would provide some valuable input but I don't think we 
should be the venue for it's development.

In 6man we have specifed how addresses are assigned to a link, different 
“types” of address and a set of properties that can be associated with an 
address (or prefix).
E.g:
  - addresses have lifetimes, (but they can be ripped away from under you with 
little notice)
  - the choice of source address essentially chooses exit path in the network
  - addresses have different privacy properties. statically configured and in 
DNS, versus randomly generated changing every hour
  - addresses have different reachability, e.g. link-local, ULA and global.
  - an IPv6 interface can have many addresses of different properties assigned 
to it

 From a 6man perspective, that’s where our competency ends. We do not know how 
this should be exposed to applications or how the transport layers should deal 
with it.
It might not be taps, but this is something we’d sorely want to punt up from 
the networking layer.

Best regards,
Ole
6man co-chair.

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


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

Re: [Taps] To registry, or not to registry?

[Gorry Fairhurst]

I quite like the idea of trying to design a simple registry format. If 
it looks good, I'd be happy to see this go forward.


Gorry

On 24/07/2018 19:13, Aaron Falk wrote:


Caveat: I am not an expert on registries but my sense is that they are 
most useful for interoperability. I think Gorry's concern about 
redundancy much less important. And, in fact, it may take a while to 
figure out how to describe the parameters. It might be more useful to 
allow for variety in how these are defined to permit creative 
approaches. YMMV of course.


--aaron

On 24 Jul 2018, at 10:06, G Fairhurst wrote:

I don't yet know for sure myself

On the one hand: I think a registry is a great way to capture the
"bundle" of things that we know about needing to send across the
API. Having common keywords (names) is a way to help people (who
wish to take this approach) from unwantingly choosing the same
function/param with a different name. And avoids accidentally
choosing the same key. I like these advantages. especially if I
thought people would use the registry.

On the other hand, as an author I am still bemused about exactly
which list of items I think /need/ could appear in this registry.
I know some I'd expect, there are some I would not be surprised to
see, and some I'd expect not to see. Also this doesn't stop people
dreaming of slight variants of functions/params because they want
to be different or don't understand/agree with another definition,
especially since the concrete API isn't specified by the IETF.

There are ways we could help support different uses, which I think
we should consider:
* We can define "well-known" IETF keywords that start with a
special prefix that require some IETF practice to assign;
* we can also define "public" keywords that have no prefix and are
first-come-first served, the easy way to get a unique entery.
* We can allow private defintions with some different prefix that
are not specified by IANA. (We simply preclude this format from
the registry).

This approach has been used in many places, a simple, but similar
transport example is the Service Codes registry:
https://www.iana.org/assignments/service-codes/service-codes.xhtml

- Let's all think about whether this is a useful approach for our API?

Gorry


On 23/07/2018, 21:32, David Schinazi wrote:

We had a similar discussion in the Babel WG regarding link
types in our data model - which isn't sent over the wire.
We landed on having an IANA registry of strings so there is
one place to find the mapping from string to specification.
We're planning on reserving all strings starting with an
underscore "_" for experimental use so the registry does not
get in anyone's way.
Apparently IANA registries have very low overhead.
Hope this helps.

David

On Jul 23, 2018, at 13:15, Tommy Pauly mailto:tpa...@apple.com>> wrote:

Hello TAPS,

Migrating a thread from GitHub to the email list, since it
needs broad WG input. I've pasted the discussion so far below.

Essentially, the question is if we have a set of standard
properties for Transport Services APIs, should they have a
formal registry or not?

Thanks,
Tommy

==

https://github.com/taps-api/drafts/issues/210

Philipp:

We will end up with a set Turns out we might need a lot of
(protocol) specific properties, we should discuss whether
we need
an IANA registry of properties and how this will look like.
• Include Types ?
• Include Names ?
• Some numeric representation ?
What do we do with ENUM values?

Mirja:

I don't really understand why we would need a registry.
Who would
be using the registry?

Tommy:

I agree that a registry seems unnecessary; this is not a
matter
of protocol or on-the-wire standard.

Philipp:

If we don't want to clutter the basic API document, we
will end
up having at least a half a dozen documents defining specific
properties for different protocols.
Does anyone have a good alternative to collect all these
except
in an IANA registry?

Tommy:

We do not need to have documents specify every property.
Implementation should be allowed to extend as they need.

Brian:

this discussion does suggest that we might want to be more
explicit up front in the interface document about the
scope and
purpose of the document (i.e. this

[Taps] Some editorial comments from a read through of draft-ietf-taps-transport-security-01

[Gorry Fairhurst]

I have just quickly read the TAPS document on transport security and 
have a few comments that may be useful for the next revision,


Gorry

---

“TCP-AO adds authenticity”
- should this be “TCP-AO adds authentication” our an authentication service?

“AH adds per-datagram authenticity”
- should this also be “authentication”.

- - -
Section 3:
“ This section contains descriptions of security protocols that
currently used to protect data being sent over a network.”
- is this /are currently used/.
- - -
“AEAD”
- please define when first used
- - -
Section 3.2.1.
“ DTLS is modified from TLS to account for packet loss, reordering, and
duplication that may occur when operating over UDP.”
- to account for doesn’t quite explain that these things happen and this 
can work with them, first time I read I wondered whether this implied 
some features to retransmit etc.

Is it clearer to say something like:
“ DTLS is modified from TLS to operate with the possibility of packet loss,
reordering, and
duplication that may occur when operating over UDP.
- - -
Similarly making this change is maybe(?) clearer:
“Since datagrams may be replayed, “
to
“Since datagrams can be replayed, “
- - -
Section 3.2.3
States a dependency on PMTU discovery. I think this dependency is on 
choosing a datgarm size (which is true of any UDP usage - section 3.2 of 
RFC8085).

—
Section 3.3 omits a reference to IETF QUIC.
- - -
Section 3.3.3,
QUIC also in the same way relies on a PMTU. (as in DTLS).
- in the same vein, I think gQUIC has chosen a fixed datgram size.
- - -
Section 3.4.1.2
“ESP Security Associations”
- I think you need to define SA here?
- - -
[RFC3545] - appears as text, rather than a reference.
- - -
Section 3.5.2
“(RFC5763) Mandatory mutually authenticated key exchange.”
- The brackets around the reference appear unusual.
- - -
Section 3.8.1
“These keys are used”
- The word /these/ reads odd, maybe:
- “The keys are used”
- - -

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

Re: [Taps] ACTION REQUIRED: updating session conflicts

[Gorry Fairhurst]

ACK - works for me, I'd love to add: intarea (as a contributor, and 
TSVWG reviewer).


My own conflicts map to what you have:
First Priority: maprg tcpm iccrg tsvwg tsvarea
Second Priority: rmcat, quic

Gorry

On 17/04/2018, 16:22, Aaron Falk wrote:


Hi Folks-

We should update our conflict list for scheduling TAPS meetings during 
the IETF week. Here’s the algorithm I’d like you to consider:


  * If you are an author/editor in TAPS and an author/editor or chair
in another wg, that is a first priority conflict
  * If you are a contributor to TAPS and an author/editor or chair in
another wg, that is a second priority conflict
  * If you are a contributor to TAPS and a contributor to another wg
(which you feel you should attend), that *may* be a conflict
depending on how many priority of the work to TAPS.
  * If you feel you “should attend” TAPS and another wg, that is not a
conflict (sorry!)

I propose the revised conflict list below based on my (imperfect) 
understanding of current TAPS contributors. There’s been some 
discussion that “third priority” is confusing to the secretariat so 
I’m hoping we can converge on just two.


Please send feedback. Thanks.

--aaron

First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic
Second Priority: tcpinc mptcp saag mmusic tram tls irtfopen

OLD:
First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic
Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag
Third Priority: mmusic tram sacm mile ipwave cfrg



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


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

Re: [Taps] [Editorial Errata Reported] RFC8095 (5285)

[Gorry Fairhurst]

This Errata seems valid. Sorry that was not spotted.

Gorry

On 12/03/2018, 03:54, RFC Errata System wrote:

The following errata report has been submitted for RFC8095,
"Services Provided by IETF Transport Protocols and Congestion Control 
Mechanisms".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5285

--
Type: Editorial
Reported by: Wesley Eddy

Section: section 3.1

Original Text
-
3.1 Transport Control Protocol (TCP)

Corrected Text
--
3.1 Transmission Control Protocol (TCP)

Notes
-
The acronym-expansion for TCP is incorrect in the section title, but is correct 
in other text within the document.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8095 (draft-ietf-taps-transports-14)
--
Title   : Services Provided by IETF Transport Protocols and 
Congestion Control Mechanisms
Publication Date: March 2017
Author(s)   : G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.
Category: INFORMATIONAL
Source  : Transport Services
Area: Transport
Stream  : IETF
Verifying Party : IESG


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

Re: [Taps] New Version Notification for draft-fairhurst-taps-neat-01.txt

[Gorry Fairhurst]

We've just posted a minor rev to the ID. It contains corrections to 
INIT_FLOW; fixes to typos.
It also includes a diagram, which we did not have time to draw before 
the meeting, but seemed useful for a discussion.


Gorry


On 13/11/2017, 13:34, internet-dra...@ietf.org wrote:

A new version of I-D, draft-fairhurst-taps-neat-01.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:   draft-fairhurst-taps-neat
Revision:   01
Title:  The NEAT Interface to Transport Services
Document date:  2017-11-13
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-fairhurst-taps-neat-01.txt
Status: https://datatracker.ietf.org/doc/draft-fairhurst-taps-neat/
Htmlized:   https://tools.ietf.org/html/draft-fairhurst-taps-neat-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-fairhurst-taps-neat-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-fairhurst-taps-neat-01

Abstract:
The NEAT System provides an example of a system designed to implement
the TAPS Transport Services.  This document presents the transport
services that the NEAT User API provides to an application or upper-
layer protocol.  It also describes primitives needed to interface to
the NEAT Policy Manager and how policies can be adjusted to match the
API behaviour to the properties required by an application or upper-
layer protocol using the NEAT User API.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Taps] IETF100 meeting agenda uploaded

[Gorry Fairhurst]

It seems to me there are many ideas that could come forward if the work 
in TAPS progresses.


To me the three IDs we currently have are quite different - and they 
seem to have different design goals. I suggest if the group is thinking 
of accepting work against the third item in the charter that it would be 
good to spend a little time to look at these proposals and then to 
explore how the various proposals fit with the "subset of Transport 
Services" resulting from the second charter item.


Best wishes,

Gorry

On 05/11/2017, 07:49, Michael Welzl wrote:

Hi,

It seems to me that this charter contains three items that relate to 
the API:

1) draft-trammell-taps-post-sockets-03
2) draft-tiesel-taps-socketintents-01
3) draft-fairhurst-taps-neat-00

...which are currently charter items 3, 4 and 6 (an unrelated - no 
less important! because it describes the implementation! - item takes 
position 5). Moreover, for the first one, it says "expected adoption 
call targeting charter item 3”.


I think it would make more sense to first hear all three proposals and 
then discuss the possible adoption of one of them?


Cheers,
Michael


On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker 
> wrote:


Hello WG,
The agenda for IETF100 has been 
uploaded_https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/_

Any comments?
BR
Zahed
*===*
*ANM ZAHEDUZZAMAN SARKER
*Ericsson Research

*Ericsson
*Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
zaheduzzaman.sar...@ericsson.com 


_www.ericsson.com_ 
===
___
Taps mailing list
Taps@ietf.org 
https://www.ietf.org/mailman/listinfo/taps




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


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

Re: [Taps] New Version Notification for draft-fairhurst-taps-neat-00.txt

[Gorry Fairhurst]

TAPers,

I've just uploaded an Internet Draft on the NEAT User API, this draft 
provides a high-level overview of the transport interface to the actual 
NEAT System (available on GIT-Hub) and outlines how this forms an API 
that can offer TAPS-like services in an actual system.


Gorry

On 30/10/2017, 15:27, internet-dra...@ietf.org wrote:

A new version of I-D, draft-fairhurst-taps-neat-00.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:   draft-fairhurst-taps-neat
Revision:   00
Title:  The NEAT Interface to Transport Services
Document date:  2017-10-30
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-fairhurst-taps-neat-00.txt
Status: https://datatracker.ietf.org/doc/draft-fairhurst-taps-neat/
Htmlized:   https://tools.ietf.org/html/draft-fairhurst-taps-neat-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-fairhurst-taps-neat-00


Abstract:
The NEAT System provides an example of a system designed to implement
the TAPS Transport Services.  This document presents the transport
services that the NEAT User API provides to an application or upper-
layer protocol.  It also describes primitives needed to interface to
the NEAT Policy Manager and how policies can be adjusted to match the
API behaviour to the properties required by an application or upper-
layer protocol using the NEAT User API.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-udp-07.txt

[Gorry Fairhurst]

TAPs people,

Here is a new revison of the ID.  We think this version addresses all 
requested changes aftre IESG review. There was also one request to 
adjust the abstract, but we have not done so (if the way in which the 
present abstract refers to taps-transport-usage is not as desired by our 
AD, we'd happily accept new text). I also note that Spencer has also 
asked a question to the list, and this revision is published while this 
is being considered.


Gorry & Tom


On 19/09/2017, 09:46, internet-dra...@ietf.org wrote:

A new version of I-D, draft-ietf-taps-transports-usage-udp-07.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:   draft-ietf-taps-transports-usage-udp
Revision:   07
Title:  Features of the User Datagram Protocol (UDP) and Lightweight 
UDP (UDP- Lite) Transport Protocols
Document date:  2017-09-19
Group:  taps
Pages:  22
URL:
https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-07
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-07

Abstract:
This is an informational document that describes the transport
protocol interface primitives provided by the User Datagram Protocol
(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport
protocols.  It identifies the datagram services exposed to
applications and how an application can configure and use the
features offered by the Internet datagram transport service.  RFC
documents the usage of transport features provided by IETF transport
protocols, describing the way UDP, UDP-Lite and other transport
protocols expose their services to applications and how an
application can configure and use the features that make up these
services.  This document provides input to and context for that
document, as well as offering a road map to documentation that may be
of help to users of the UDP and UDP-Lite protocols.

XXX RFC-Ed Note - please replace RFC with the published RFC
number for I-D.ietf-taps-transports-usage, when these documents are
both published XXX.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

[Gorry Fairhurst]

On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:

And, following up during the actual telechat ...

On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF 
mailto:spencerdawkins.i...@gmail.com>> 
wrote:


Dear TAPS working group,

Multiple ADs have asked why these two drafts aren't a single
draft, in their ballots. Those are non-blocking comments, but I'd
like to explore that, before making a decision about what should
happen, and when.

It occurs to me that these ADs are reading both drafts pretty much
back-to-back in preparation for balloting during IESG Evaluation.

If people reading the two drafts back-to-back find the split to be
a distraction, I'd like to understand the views of the working
group as to how often you expect people to read both drafts, in
order to do TAPS.

I could imagine that people working on complete TAPS APIs might
need to read both drafts.

What about other folks you expect to read these documents? Do you
expect that some communities only need to read one of them?

Thanks in advance for any thoughts you can share.

Spencer, as responsible AD for TAPS


Both documents were approved on the telechat today, pending comment 
resolution of comments received during IESG Evaluation.


So, my request to the working group to consider whether the suggestion 
to combine these documents makes life easier for the readers you 
expect will need to read one, the other, or both documents REALLY IS 
an honest question, and not the IESG requiring fabulously late major 
editorial changes without an active Discuss, because That Would Be Wrong.


Either answer works. We'll Do The Right Thing.

"Thanks in advance for your thoughts" :-)

Spencer, as responsible AD, who the IESG said they trusted to "Do The 
Right Thing"



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


There was a proposal from IESG to consider whether we should merge the 
two usage documents. So after giving this some more thought, here is my 
2c about why I think we should keep the two documents:


First, I accept it may be easier for someone reviewing the history of 
TAPS and the rationale for design decisions to read just a single 
document - putting all the material in one place is always easier. 
However, if published in consecutive RFCs, I'm not convinced the 
material would be really hard for a reader to find.


I suggested there were two reasons behind separating this out when we 
did the work. First, the old and incomplete documentation for UDP needed 
a slightly different approach to finding the relevent RFCs. Second, the 
community of interest in using UDP at the IETF is typically to be found 
outside the TSV area, partly because of the wide variety of uses. A 
second document made this easier for these people to read. That's still 
the case for the material that was retained in the UDP usage document.


It would be my hope that the UDP document could form a long-needed part 
of the documentation for UDP. I expect this would continue to be a 
useful resource for anyone who wishes to build datagram support into a 
new stack, or just wants to program to this API, and avoids people 
needing to wade through 50-60 pages to find a section on a UDP API. I'd 
also hope (??!!) this document could be maintained in future as the API 
continues to develop.


Gorry


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

Re: [Taps] Benoit Claise's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

[Gorry Fairhurst]

On 14/09/2017, 14:05, Benoit Claise wrote:

Benoit Claise has entered the following ballot position for
draft-ietf-taps-transports-usage-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/



--
COMMENT:
--

Interesting piece of work. Thanks.
I hope it will be maintained along the time

I really hope so too !!!

Acknowledgement: "The views expressed are solely those of the author(s)."
Really? Why this sentence?
It was because it was what the funders requested for the individual 
draft and was never removed when the WG adopted it. Thanks for reading 
to the very end, --  I shall certainly remove this sentence in the next 
rev.!


Gorry


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


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

Re: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT)

[Gorry Fairhurst]

Thanks Suresh, please see below.

On 14/09/2017, 00:12, Suresh Krishnan wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-taps-transports-usage-udp-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/



--
COMMENT:
--

* Section 1

"The UDP and UDP-Lite sockets API differs from that for TCP in several key
ways."

I was expecting the document to at least briefly describe the differences
following this. The socket option text that follows does not really fit the
bill. e.g. SO_REUSEADDR applies to TCP as well as UDP.


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
I see, that wasn't quite the way I expected it to be read, so maybe we 
can suggest a slight re-write to the introduction to avoid misleading 
people and thereby better introduce what follows in the document:


After the reference to Stevens, we suggest to insert:

"In UDP and UDP-Lite, each datagram is a self-contained message of a 
specified length, and options at the transport layer can be used to set 
properties for all subsequent datagrams sent using a socket or changed 
for each datagram. For datagrams, this can require the application to 
use the API to set IP-level information (the IP Time To Live (TTL), 
Differentiated Services (DiffServ) Code Point, IP fragmentation, etc) 
for the datagrams it sends and receives. In contrast, when using TCP and 
other connection-oriented transports, the IP-level information normally 
either remains the same for the duration of a connection or is 
controlled by the transport protocol rather than the application.


Socket options are used in the socket API to provide additional 
functions Examples of socket options (in this case commonly used by UDP 
multicast applications) include:"


... followed by the three example sockopts.

(If we add this I think it also helps explain why the network-layer 
primitives appear. We would of course avoide redefining TTL, etc in the 
following paras.)


Tom & Gorry

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

Re: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

[Gorry Fairhurst]

On 11/09/2017, 16:48, Mirja Kühlewind wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-taps-transports-usage-08: No Objection




--
COMMENT:
--



- I (still) don't understand why draft-ietf-taps-transports-usage-udp was kept
in a separate document, given there is even a separate empty section in this
doc. You basically have to stop reading there, go to the other doc, read it,
and come back. That doesn't make sense to me.


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

I'll speak only to the last comment which was discussed in IETF-96.

The WG looked at this and there were pro's and con's in both a single 
document, and two separate documents. In the end, the decision by the WG 
was to publish the initial datagram analysis (UDP and UDP-L) as a 
separate document, which cut them into smaller pieces and was more 
managebale, but the WG would request the RFC-Ed to publish the two 
documents as a pair.


I see another advantage: Much of the API requirements for UDP is 
scattered across various RFCs - and some implicit (RFCs that state a 
need to allow the stack to do something, but do not indicate how it will 
be done). It was thought a separate datagram document may have further 
utility for people as a informative single reference on how to present a 
datagram API, beyond its input to the TAPs transport design.


Gorry

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

Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT)

[Gorry Fairhurst]

Hi Eric,

The text you mention is the final para of section 3 of RFC 7413. I 
suspect the most appropriate correction would be to identify the section 
number in the text, as done for other cited RFCs, e.g. Section 3 of 
RFC7413 states that a TCP implementations MUST NOT use TFO by default, 
but only use TFO if requested explicitly by the application on a 
per-service-port basis.


Gorry

On 11/09/2017, 15:13, Eric Rescorla wrote:

Eric Rescorla has entered the following ballot position for
draft-ietf-taps-transports-usage-08: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/



--
COMMENT:
--

I have not yet completed my review of this document, but I note that it is
targeted for Informative but also contains RFC2119 normative language, e.g.,

"TCP implementations MUST NOT use
  TFO by default, but only use TFO if requested explicitly by the
   application on a per-service-port basis."

If the intent is that this is to be Informational then this should be removed,
and if it's to be BCP, then it needs to go back to IETF-LC for that


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


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

[Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt

[Gorry Fairhurst]

This new revision updates the draft to address AD review comments, and 
to align the source with ID's that have now been published as RFCs.


Best wishes,

Gorry & Tom

 Original Message 
Subject: 	New Version Notification for 
draft-ietf-taps-transports-usage-udp-05.txt

Date:   Wed, 30 Aug 2017 02:19:23 -0700
From:   internet-dra...@ietf.org
To: 	Tom Jones , Godred Fairhurst 
, Gorry Fairhurst 




A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:   draft-ietf-taps-transports-usage-udp
Revision:   05
Title:  Features of the User Datagram Protocol (UDP) and Lightweight 
UDP (UDP- Lite) Transport Protocols
Document date:  2017-08-30
Group:  taps
Pages:  21
URL:
https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-05
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-05

Abstract:
   This is an informational document that describes the transport
   protocol interface primitives provided by the User Datagram Protocol
   (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport
   protocols.  It identifies the datagram services exposed to
   applications and how an application can configure and use the
   features offered by the Internet datagram transport service.  RFC
   documents the usage of transport features provided by IETF transport
   protocols, describing the way UDP, UDP-Lite and other transport
   protocols expose their services to applications and how an
   application can configure and use the features that make up these
   services.  This document provides input to and context for that
   document, as well as offering a road map to documentation that may be
   of help to users of the UDP and UDP-Lite protocols.

   XXX RFC-Ed Note - please replace RFC with the published RFC
   number for I-D.ietf-taps-transports-usage, when these documents are
   both published XXX.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Taps] AD review of draft-ietf-taps-transports-usage-udp-04

[Gorry Fairhurst]

Thanks Spencer,

I have added new text which I hope addresses these issues in the next 
revision.


Gorry

On 24/08/2017, 21:09, Spencer Dawkins at IETF wrote:
I'm actually pretty positive on this draft - most of what follows is 
editorial.


Thanks,

Spencer

This text

This document is intended as a contribution to the Transport Services
(TAPS) working group to assist in analysis of the UDP and UDP-Lite
transport interface.

Refers to the TAPS working group, which will conclude someday. It’s 
probably better if you say that this document provided details for the 
Pass 1 analysis of UDP and UDP-Lite that is used in 
draft-ietf-taps-transports-usage-06, or something like that.


In this text

Neither UDP nor UDP-Lite provide congestion control, retransmission,
nor do they have support to optimise fragmentation and other
transport functions.

Is “optimizing fragmentation” the best way to describe what UDP is not 
doing there? Perhaps “assist in application-level packetization that 
would avoid IP fragmentation?”


I may be very confused about this next one, but in

Messages passed to the send
primitive that cannot be sent atomically in a datagram will not be
sent by the network layer, generating an error.

Is this “atomically in an IP datagram”? With IP-level fragmentation 
available, I’m not sure what “atomically” is telling the reader.


If we’re going to “go there”, this text

The acceptable maximum packet size can be determined using
Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path
MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis].

Makes PMTUD sound like an equally good alternative. What ended up in 
-08 of [I-D.ietf-6man-rfc1981bis], and in RFC 8201, and I saw that 
your reference was to -06, is


If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big
messages, the source will not learn the actual path MTU.
Packetization Layer Path MTU Discovery [RFC4821] does not rely upon
network support for ICMPv6 messages and is therefore considered more
robust than standard PMTUD. It is not susceptible to "black holed"
connections caused by filtering of ICMPv6 message. See [RFC4890] for
recommendations regarding filtering ICMPv6 messages.


I know we don’t have a great story for discovering maximum packet 
sizes, but I’d like to be at least as discouraging about PMTUD as RFC 
8201, and concerns about earlier versions of the text almost prevented 
RFC 8201 from being published as an Internet Standard, and I’m pretty 
sure being more encouraging would gather Discusses - 
https://datatracker.ietf.org/doc/rfc8201/history/ is instructive.



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


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

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Gorry Fairhurst]

Thanks for dealing with this, comments in-line.

On 16/05/2017 15:09, Michael Welzl wrote:

Hi,

Thanks a lot for your comments!  Answers in line below, marked with [Michael]. When I say 
"done" I mean my local copy - still need to fix some more nits, but I thought 
sharing this answer already now is useful.

Cheers,
Michael





2.  Introduction

  This document presents defined interactions between applications and
  the transport protocols TCP, MPTCP, SCTP, UDP and UDP-Lite as well as
  the LEDBAT congestion control mechanism in the form of primitives and
  Transport Features.  Primitives can be invoked by an application or a
  transport protocol; the latter type is called an "event".  The list
  of primitives and Transport Features in this document is strictly
  based on the parts of protocol specifications that describe what the
  protocol provides to an application using it and how the application
  interacts with it.  Together with [RFC8095], it provides the basis
  for the minimal set of transport services that end systems should



Welzl, et al.Expires October 7, 2017[Page 3]

Internet-Draft Transport Services April 2017


  support; this minimal set is derived in
  [I-D.draft-gjessing-taps-minset].


What is the relationship to usage-udp?

ADD:
UDP and UDP-Lite protocols are analysed in Features of the User
Datagram (UDP) and Lightweight UDP (UDP-Lite) Transport
   protocols [FJ16].


[Michael] I addressed this, but differently because I think repeating the title 
of FJ16 doesn't make this sentence very readable. Here's my new version of the 
paragraph's last sentence:

***
   Together with an overview
   of the services provided by IETF transport protocols and and
   congestion control mechanisms [RFC8095] and an analysis of UDP and
   UDP-Lite [FJ16], it provides the basis for the minimal set of
   transport services that end systems should support [I-D.draft-
   gjessing-taps-minset].
***




  Parts of a protocol that are explicitly stated as optional to
  implement are not covered.  Interactions between the application and
  a transport protocol that are not directly related to the operation
  of the protocol are also not covered.  For example, [RFC6458]
  explains how an application can use socket options to indicate its
  interest in receiving certain notifications.  However, for the
  purpose of identifying primitives and Transport Services, the ability
  to enable or disable the reception of notifications is irrelevant.
  Similarly, one-to-many style sockets described in [RFC6458] just
  affect the application programming style, not how the underlying
  protocol operates, and they are therefore not discussed here.  The
  same is true for the ability to obtain the unchanged value of a
  parameter that an application has previously set (this is the case
 for the "get" in many get/set operations in [RFC6458]).

  The document presents a three-pass process to arrive at a list of
  Transport Features.  In the first pass, the relevant RFC text is
  discussed per protocol.  In the second pass, this discussion is used
  to derive a list of primitives that are uniformly categorized across
  protocols.  Here, an attempt is made to present or -- where text
  describing primitives does not yet exist -- construct primitives in a
  slightly generalized form to highlight similarities.  This is, for
  example, achieved by renaming primitives of protocols or by avoiding
  a strict 1:1-mapping between the primitives in the protocol
  specification and primitives in the list.  Finally, the third pass
  presents Transport Features based on pass 2, identifying which
  protocols implement them.

  In the list resulting from the second pass, some Transport Features
  are missing because they are implicit in some protocols, and they
  only become explicit when we consider the superset of all features
  offered by all protocols.  For example, TCP always carries out
  congestion control; we have to consider it together with a protocol
  like UDP (which does not have congestion control) before we can
  consider congestion control as a Transport Feature.  The complete
  list of features across all protocols is therefore only available
  after pass 3.


This needs an intro to the document separate to the overview of the
process

The document needs to start with an introduction to the document
separate of the overview of the process, so that anyone reading thsi
knows whether t read more. Perhaps this should be the first section?


  This document discusses unicast transport protocols and a unicast
  congestion control mechanism.  Transport protocols provide
  communication between processes that operate on network endpoints,
  which means that they allow for multiplexing of communication between
  the same IP addresses, and normally this multiplexing is achieved
  using port numbers.  Port multiplexing is therefore assumed to be
  always pro

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Gorry Fairhurst]

More below.

On 12/05/2017, 16:27, Michael Welzl wrote:

On May 12, 2017, at 3:24 PM, Gorry Fairhurst  wrote:

See below.

On 12/05/2017, 13:31, Michael Welzl wrote:

Hi,

Thanks a lot for all your comments (plus the nits we authors of the other 
-usage draft received offline).

I’ll try to address them all - but there are a two technical questions in this 
email that made me stop, so I’ll cut all the editorial stuff away and discuss 
them here - in line below:



- Why do this??? - Isn't it better to set flow labels per interface or for the 
whole stack, how can any specific transport or application pick unique labels?
TEXT:

   o  Specify IPv6 flow label field
  Protocols: SCTP

(i.e., Is this automatable by the host and a host wide
configuration?)

Somehow the question seems irrelevant in the context of this draft, which is a 
list of transport features of protocols. These features are defined in the RFCs 
spec’ing the protocols - for SCTP, this is defined, and that’s why it’s here.

We can discuss this for the proposed services that a system should offer, which 
we try to write up in the minset draft:
I do think that an application should be allowed to assign a label to a TAPS 
flow (as we call them), which could then map to this function. I mean, isn’t a 
flow label supposed to identify a transport flow? Then a system-wide 
configuration wouldn't seem right to me.

I think we may disagree. Flow ids identify flows to the network layer, they 
have no role at the transport layer, and need to be unique (as best they can) 
for a source address.

We disagree indeed - in particular about the “unique (as best they can)..” bit. 
Where is this written??
I'm taking the position of using this as input to an ECMP or LAG hash 
algorithm.



I much prefer the idea that the Flow id is generated by the IP system, by using 
a hash - possibly utilising transport data as a part of this hash, and 
including the protocol number.

RFC 6437 introduces the flow label as a replacement for the 5-tuple - “possibly 
utilising transport data as a part of this hash” seems to me to be a very weak 
requirement here!

OK, which I think is the idea in RFC6438.

Anyway classifiers in the network wouldn’t work on the flow label alone, but, 
from RFC 6437, section 2 which is called “specification”:
   "Packet classifiers can
use the triplet of Flow Label, Source Address, and Destination
Address fields to identify the flow to which a particular packet
belongs."

Yes.

Then what is the flow label good for, if it’s unique per source address? It 
doesn’t add any information to this 3-tuple in this case!
Aha - I mean each "microflow" sent from a specific source address should 
be identified by a different and unique flow ID.

That seems to be what ECMP is expecting and I suspect ECMP is an improtant 
use-case.

The alternative (if I understand) could be: I could imagine each application 
could (in theory) be provided with an API to find out what flow-ids are 
currently being used for each interface it cares about and to then reserve one 
of the unused IDs for the specific interface(s) that it wishes to use. Then we 
need to ensure all upper layer entities coordinate on this. To me, this seems 
over-kill, and the approach taken with ephemeral port assignment is much 
simpler - the application simply doesn't get involved with choosing the number.

Now if what you are saying is that you want the App to somehow signal that it 
can use an existing flow ID that is in use, and combine data with that flow to 
get the same network treeatment, I can understand the case. However, that's not 
exactly the same thing.

I understand that it would be nice to avoid upper-layer coordination here. 
However, I see at least two use cases for the application being more in control:
1) avoiding fate sharing (encouraging ECMP), e.g. for increased resilience
Yes. Part of the idea here is that microflows (say with the same IPsec 
ESP) can now be separately forwarded if that is what is desired by the 
sending endpoint.

2) the opposite: grouping flows, to be able to apply priorities on them, using 
a mechanism such as the Congestion Manager or 
https://tools.ietf.org/html/draft-welzl-tcp-ccc
That's the converse of the IPsec ESP example above, and also ok if the 
endpoint wishes this.

So this is not about giving the application control of the specific flow label 
number, but allowing it to say “use the same number for these flows” or not.
That's fine with me. Providing it is *NOT* the flow-id, but an input to 
the function that determines the flow-id.

I think this could nicely be done by letting it number flows, and grouping them 
via equal numbering - without guaranteeing that these numbers map onto the 
exact same numbers as a flow label.

OK.



---
Get Interface MTU is missing from pass 2 and 3:

ADD to pass 2:

GET_INTERFACE_MTU.UDP:
Pass 1 primit

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Gorry Fairhurst]

See below.

On 12/05/2017, 13:31, Michael Welzl wrote:

Hi,

Thanks a lot for all your comments (plus the nits we authors of the other 
-usage draft received offline).

I’ll try to address them all - but there are a two technical questions in this 
email that made me stop, so I’ll cut all the editorial stuff away and discuss 
them here - in line below:



- Why do this??? - Isn't it better to set flow labels per interface or for the 
whole stack, how can any specific transport or application pick unique labels?
TEXT:

   o  Specify IPv6 flow label field
  Protocols: SCTP

(i.e., Is this automatable by the host and a host wide
configuration?)

Somehow the question seems irrelevant in the context of this draft, which is a 
list of transport features of protocols. These features are defined in the RFCs 
spec’ing the protocols - for SCTP, this is defined, and that’s why it’s here.

We can discuss this for the proposed services that a system should offer, which 
we try to write up in the minset draft:
I do think that an application should be allowed to assign a label to a TAPS 
flow (as we call them), which could then map to this function. I mean, isn’t a 
flow label supposed to identify a transport flow? Then a system-wide 
configuration wouldn't seem right to me.
I think we may disagree. Flow ids identify flows to the network layer, 
they have no role at the transport layer, and need to be unique (as best 
they can) for a source address.


I much prefer the idea that the Flow id is generated by the IP system, 
by using a hash - possibly utilising transport data as a part of this 
hash, and including the protocol number. That seems to be what ECMP is 
expecting and I suspect ECMP is an improtant use-case.


The alternative (if I understand) could be: I could imagine each 
application could (in theory) be provided with an API to find out what 
flow-ids are currently being used for each interface it cares about and 
to then reserve one of the unused IDs for the specific interface(s) that 
it wishes to use. Then we need to ensure all upper layer entities 
coordinate on this. To me, this seems over-kill, and the approach taken 
with ephemeral port assignment is much simpler - the application simply 
doesn't get involved with choosing the number.


Now if what you are saying is that you want the App to somehow signal 
that it can use an existing flow ID that is in use, and combine data 
with that flow to get the same network treeatment, I can understand the 
case. However, that's not exactly the same thing.

---
Get Interface MTU is missing from pass 2 and 3:

ADD to pass 2:

GET_INTERFACE_MTU.UDP:
Pass 1 primitive: GET_INTERFACE_MTU
Returns: Maximum datagram size (bytes)

But this doesn’t exist!
I think I don't understand your comment ... and interpretting 
low-numbered RFCs is never easy -  I'll use RFC1122 as my basis:


RFC 1122 says:
   " A host MUST implement a mechanism to allow the transport layer
 to learn MMS_S, the maximum transport-layer message size that
 may be sent for a given {source, destination, TOS} triplet..."
   " and EMTU_S must be less than or equal to the MTU of the network
 interface corresponding to the source address of the datagram."

TCP handles this for the app.

  It’s strictly an IP function and I couldn’t find it described for UDP 
anywhere. I think we agreed on how a TAPS system should handle this, and this 
is reflected in
https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1
… which may require a system to implement new local functionality, maybe based 
on this MTU function - but to my understanding it’s just not something that UDP 
offers.
It's something that a UDP App really needs to pay attention to as per 
RFC8085 - we may differ on whether you call that "offers" or needs to 
function. Either way, an app that plans to use any form of PMTUD needs 
to use this number.


As put in RFC1122:
   " A host that does not implement local fragmentation MUST ensure
 that the transport layer (for TCP) or the application layer
 (for UDP) obtains MMS_S from the IP layer and does not send a
 datagram exceeding MMS_S in size."


Cheers,
Michael

Gorry

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

[Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Gorry Fairhurst]

t/received
>  on this connection.
NEW:
o  ABORT.UDP(-Lite):
   Pass 1 primitive event: 'CLOSE'
   Comments: this terminates a connection without delivering
   remaining data.  No further UDP(-Lite) datagrams are
   sent/received for this transport service instance.

- For UDP, this is just an error report, remove.
DELETE:
>   o  SEND_FAILURE.UDP(-Lite):
>  Pass 1 primitive / event: 'SEND'
>  Comments: This may be used to probe for the effective PMTU when
>  using in combination with the 'MAINTENANCE.SET_DF' primitive.

- UDP can't do this,  remove UDP(-Lite)
OLD:
>   o  Listen, N specified local interfaces
>  Protocols: SCTP, UDP(-Lite)
NEW:
o  Listen, N specified local interfaces
   Protocols: SCTP
- UDP can potentially also do this (for some options on all packets)
OLD:
>   o  Specify which IP Options must always be used
>  Protocols: TCP
NEW:
   o  Specify which IP Options must always be used
  Protocols: TCP, UDP(-Lite)

- Why do this??? - Isn't it better to set flow labels per interface or 
for the whole stack, how can any specific transport or application pick 
unique labels?

TEXT:
>   o  Specify IPv6 flow label field
>  Protocols: SCTP

(i.e., Is this automatable by the host and a host wide
configuration?)

---
Get Interface MTU is missing from pass 2 and 3:

ADD to pass 2:

GET_INTERFACE_MTU.UDP:
Pass 1 primitive: GET_INTERFACE_MTU
Returns: Maximum datagram size (bytes)

ADD to Pass 3,
MAINTENANCE:

Get interface MTU
Protocols: UDP

- Move the per-datagram IP options to be placed next to the other IP 
options primitives:


MOVE:
>   o  Specify IP Options
>  Protocols: UDP(-Lite)
>
MOVE:
>   o  Obtain IP Options
>  Protocols: UDP(-Lite)


- Please remove UDP(-Lite), it does not make sense to do thisfrom 5.2.3. 
 Errors:


OLD:
>   o  Notification of an unsent (part of a) message
>  Protocols: SCTP, UDP(-Lite)

NEW:
o  Notification of an unsent (part of a) message
   Protocols: SCTP
--

> 8.  Security Considerations
>
>   Authentication, confidentiality protection, and integrity protection
>   are identified as Transport Features by [RFC8095].  As currently
>   deployed in the Internet, these features are generally provided by a
>   protocol or layer on top of the transport protocol; no current full-
>   featured standards-track transport protocol provides these features
>   on its own.  Therefore, these features are not considered in this
>   document, with the exception of native authentication capabilities of
>   TCP and SCTP for which the security considerations in [RFC5925] and
>   [RFC4895] apply.
>

- We think it is also important discussion from usage-udp:
ADD:
  Security considerations for the use of UDP and UDP-Lite are
  provided in the referenced RFCs. Security guidance for
  application usage is provided in the UDP-Guidelines .
--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.

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

Re: [Taps] Comments on draft-gjessing-taps-minset-02 - just DSCP

[Gorry Fairhurst]

On 26/03/2017, 13:59, Michael Welzl wrote:

On Mar 26, 2017, at 12:13 PM, Gorry (erg)  wrote:


This reply is just about the DSCP and QoS.

Everything you say about TAPS trying to set DSCP values seems consistent with 
normal diffserv use to me: Just because an app sets a DSCP does not mean the 
actually sent packets are assigned a PHB along the path, it simply marks them 
for this treatment, and packets may also be remarked or dropped. Since there 
are no guarentees, there is no need for a primitive telling an app it did not 
get what it hoped for. So to me, this is normal Diffserv QoS treatment. No 
guarentees.

But not even guaranteeing that packets will be marked would go to far? Or 
wouldn’t it?
It clearly doen't help deploy diffserv if your local system bleaches the 
DCSP value to zero. That happens though. So we need to live with that. 
I'd therefore say it is OK.

(Just checking - because I think we could make the system guarantee that, as all 
transports allow setting the DSCP; it was just my decision to combine DSCP-setting with a 
few other things together and call them "capacity profile", but that’s 
certainly up for debate).


That's more interesting to debate.

The words in the charter say "
Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a 
plea not to redesign NSIS RSVP etc…

That would be my interpretation too.

Cheers,
Michael

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

Gorry

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

[Taps] Comments on draft-gjessing-taps-minset-02

[Gorry Fairhurst]

This looks like good progress. A few very specific comments below:

---
I see phrase:
"   Because QoS is out of scope of TAPS, this document assumes a "best
   effort" service model [RFC5290], [RFC7305].  "

I'm not sure we need to state this. Although I agree that TAPS will not 
propose new QoS techniques, the service provided by TAPS is, I think, 
also not confinded to "best effort".


---
I am not sure that IP options from UDP are entirely automatbale. 
Per-packet IP options could be related to application use of the 
network, and I think this would require some form of API interaction.


---
I see LE service as something interesting, yet this does not exactly fit 
the rest of the draft. The cited reference is to a DiffServ PHB, and the 
LEDBAT referenced is a transport protocol mechanism, not a protocol. I'm 
not sure this inclusion is justified in the current tetx.

---
Abort without delivering...

Abortis currently specified for SCTP and TCP. If one assumes the bound 
semantics for UDP(Lite) this also seems also the correct primitive for 
UDP(Lite.


Should this ID specify a connect primitive also for bound use of UDP(Lite)?

---

What should be said about SCTP usage of IP OPTIONS? I would have 
expected if the endpoint network layer set these, they would also work 
for SCTP?


---

Finally,

I think I can agree the argument that UDP(Lite) message handling is 
different to SCTP.


---

Gorry

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

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

It seems we can not find a common basis here. See below:

On 14/12/2016 01:23, Joe Touch wrote:



On 12/13/2016 5:34 AM, Gorry Fairhurst wrote:

...


(1) I think we need a parameter returned to the App that is
equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is
useful to know how many bytes the app can send with reasonable
chance of unfragmented delivery.


All we can know is whether it is unfragmented at the next layer down.

I disagree. The stack can tell the App a MPS value based on PMTUD (when 
it implements this, or understanding of headers). That's already 
specified for SCTP & DCCP. Sure, the path may change, but at least the 
App can access a recent result.





(2) It's helpful for Apps to be able to retrieve the upper size
allowed with potential fragmentation - that could be useful in
determinine probe sizes for an application.  Apps should know the
hard limt, In DCCP this is called the current congestion control
maximum packet size (CCMPS), the largest permitted by the stack
using the current congestion control method. That's bound to be less
than or equal to what is permitted for the local Interface MTU. This
limit lets the App also take into consideration other size
constraints in the stack below the API.



Again, next layer down only. We're generally talking about existing
transports that try to pass the link MTU up through network and
transport transparently, but that need not be the case. Keep in mind
that the link MTU for ATM AAL5 isn't 48B, it's 9K - i.e., it is the
message that the link will deliver intact, not the native link size.
...

>
In this case, I think you are wrong, sorry. Apps can be told the largest 
message they can send over a transport. And some transports do in fact 
limit this.


I don't see the relevance of the ATM example. Datagram protocols work at 
the transport layer.



(3) Apps need to be able to ask the stack to try hard to send
datagrams larger than the current MPS -


I disagree.


We don't agree. Apps can send probe messages.


The app should see two values from transport:

A) how big a message can you deliver at all?

- Wasn't that the thing I originally cited as CCMPS

B) how big a message can you deliver "natively"?

- Wasn't that MPS?


Any probing happens between those two values.


That's a true!


This is not expected as the default, the stack needs to be told to
enable this use of source/router fragmentation and send IPv4 datagrams
with DF=0 (For some IPv4 paths, the PMTU, and hence MPS can be very
small).


I disagree.

DF=0 is a network flag that should never be exposed to the app. Even if
it is, this wouldn't be the control the app really wants. The app would
want to prevent source fragmentation. DF=0 applies to IPv4 only and only
affects *on path* fragmentation.

But that's not the transport's job.

I disagree, if  MPS > datagram > CCMPS the stack needs to know whether 
to source fragment (3), or for IPv4 whether to allow network 
fragmentation (4). Potentially you could discard if neither (3) or (4) 
is allowed.



Consider this:
- transport has max and native message sizes
- network has max and native message sizes
- link has max and native message sizes

Every layer has these. Sometimes they're the same (when a layer doesn't
support frag/reassembly , e.g., UDP,

>
UDP does support fragmentation.


 Ethernet)

... Which is link layer.


, sometimes they're not
(IP, TCP). Somtimes they're unlimited (TCP has no max message size, AFAICT).

TCP isn't datagram either - and is stream-based - so segments are not 
necessarily packets.



(4) Apps need to be able to ask the stack to send datagrams larger
than the current MPS, but NOT if this results in source fragmentation.

Apps can control only transport fragmentation. They can't and shouldn't
see or control network or link fragmentation UNLESS transport lets that
pass through as a transport behavior.

If we were talking about TCP-like protocols that would be fine, but I'm 
talking about datagram protocols where the PDU being sent is a datagram.



Such packets need to be sent with DF=1.  - This is not expected as the
default, the stack needs to be told to enable this -  for UDP it would
be needed to perform PMTUD. That's I think what has been just called
"native transmission desired ".


The issue is that this is an interaction between the app and transport.
It has nothing to do with the network or link layers  - unless the
transport wants it to. It's up to the transport to decide whether to try
to "pass through" the native network size. It's up to the network layer
to decide whether to "pass through" the native link size.

E.g., for IPv6, the lowest values to the answers above are:
A) 1500B, including IP header and options
B) 1280B, including IP header and options

That necessa

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

On 13/12/2016 12:53, Michael Welzl wrote:

On 13 Dec 2016, at 11:05, Gorry Fairhurst  wrote:

On 13/12/2016 09:13, Michael Welzl wrote:

Hi,

This direction definitely makes sense to me, too. I see some tension here, though - on 
the one hand, Joe is (as usual) arguing "cleanliness", i.e. keep layering 
right. On the other hand, applications tend to want to know a message size that doesn't 
get fragmented along an IPv4 path (as identified by the authors of 
draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services).
Raising the abstraction level is fine, but I think Joe's suggestion below 
misses something.

In an earlier email, Joe wrote about these two sizes:

***
1) the size of the message that CAN be delivered at all

2) the size of the message that can be delivered without network-layer
fragmentation
***
and stated that 2) should not be exposed.

So, in the proposal below, "largest transmission size" is 1) from above, and sending it 
would fail if it's bigger than 2) above AND "native transmission desired" is set to TRUE. 
So this is how the application would then do its own form of PMTUD.

Given that we don't know which protocol we're running over, probing strategies 
that involve common MTU sizes (like using the table in section 7.1 of RFC1191) 
can't work. So it's not the world's most efficient PMTUD that applications will 
be using, to eventually find the value of 2).
A protocol like SCTP is even going to do PMTUD on its own, so it could provide a number for 2), which 
would have less overhead than requiring applications to do their own PMTUD.  =>If we have to 
"go dirty" anyway, which we already do by exposing the binary "native transmission 
desired", why not offer the value of 2) as well?
In other words: how is this boolean better than offering 2) ?

Cheers,
Michael




On 12 Dec 2016, at 21:53, Gorry (erg)   wrote:

This is fine - it looks a like what I pointed to in the DCCP spec. But 
specifically,  I agree you don't need the DF flag visible - if you have a way 
to convey the info needed to set the flag at the transport (and anything else 
appropriate -as you note). I am all in favour of such appropriate abstraction.

Gorry


On 12 Dec 2016, at 19:09, Joe Touch   wrote:


On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:

IMO, the app should never need to play with DF. It needs to know what it
thinks the transport can deliver - which might include transport
frag/reassembly and network frag/reassembly.

How does the App handle probes for path MTU then in UDP?

Gorry

I think there needs to be two parts to the API:

- largest transmission size
- native transmission desired (true/false)

If the app says "YES" to native transmission size, then that would suggest that 
UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not 
only set DF=1, but also not source fragment.

I.e., I don't think it's the app's job to know how to explicitly control a mechanism two 
layers down, and DF isn't really what you want anyway. DF isn't the same as "don't 
source fragment".

Joe
___
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

So I'd like to return to RFCs that have been through part of this discussion 
before,

(1) I think we need a parameter returned to the App that is equivalent to 
Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how many 
bytes the app can send with reasonable chance of unfragmented delivery.

I agree; that seems to be what I ended up proposing above.



(2) It's helpful for Apps to be able to retrieve the upper size allowed with 
potential fragmentation - that could be useful in determinine probe sizes for 
an application.  Apps should know the hard limt, In DCCP this is called the 
current congestion control maximum packet size (CCMPS), the largest permitted 
by the stack using the current congestion control method. That's bound to be 
less than or equal to what is permitted for the local Interface MTU. This limit 
lets the App also take into consideration other size constraints in the stack 
below the API.

Agreed; I think that was Joe's item 1) ("the size of the message that CAN be 
delivered at all").



(3) Apps need to be allowed to fragment datagrams more than MPS - This is not 
expected as the default, the stack needs to be told.

(4) Apps need to be allowed to not allow datagram fragmentation - The stack 
needs to be told. You could do this by using the DF semantics (i.e., don't 
source fragment a DF-marked packet). Thinking more, this seems the easiest.

These two are hard to parse,

Sorry - trying hard.

making me wonder if they mean what

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

On 13/12/2016 09:13, Michael Welzl wrote:

Hi,

This direction definitely makes sense to me, too. I see some tension here, though - on 
the one hand, Joe is (as usual) arguing "cleanliness", i.e. keep layering 
right. On the other hand, applications tend to want to know a message size that doesn't 
get fragmented along an IPv4 path (as identified by the authors of 
draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services).
Raising the abstraction level is fine, but I think Joe's suggestion below 
misses something.

In an earlier email, Joe wrote about these two sizes:

***
1) the size of the message that CAN be delivered at all

2) the size of the message that can be delivered without network-layer
fragmentation
***
and stated that 2) should not be exposed.

So, in the proposal below, "largest transmission size" is 1) from above, and sending it 
would fail if it's bigger than 2) above AND "native transmission desired" is set to TRUE. 
So this is how the application would then do its own form of PMTUD.

Given that we don't know which protocol we're running over, probing strategies 
that involve common MTU sizes (like using the table in section 7.1 of RFC1191) 
can't work. So it's not the world's most efficient PMTUD that applications will 
be using, to eventually find the value of 2).
A protocol like SCTP is even going to do PMTUD on its own, so it could provide a number for 2), which 
would have less overhead than requiring applications to do their own PMTUD.  =>   If we have to 
"go dirty" anyway, which we already do by exposing the binary "native transmission 
desired", why not offer the value of 2) as well?
In other words: how is this boolean better than offering 2) ?

Cheers,
Michael




On 12 Dec 2016, at 21:53, Gorry (erg)  wrote:

This is fine - it looks a like what I pointed to in the DCCP spec. But 
specifically,  I agree you don't need the DF flag visible - if you have a way 
to convey the info needed to set the flag at the transport (and anything else 
appropriate -as you note). I am all in favour of such appropriate abstraction.

Gorry


On 12 Dec 2016, at 19:09, Joe Touch  wrote:


On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:

IMO, the app should never need to play with DF. It needs to know what it
thinks the transport can deliver - which might include transport
frag/reassembly and network frag/reassembly.

How does the App handle probes for path MTU then in UDP?

Gorry

I think there needs to be two parts to the API:

- largest transmission size
- native transmission desired (true/false)

If the app says "YES" to native transmission size, then that would suggest that 
UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not 
only set DF=1, but also not source fragment.

I.e., I don't think it's the app's job to know how to explicitly control a mechanism two 
layers down, and DF isn't really what you want anyway. DF isn't the same as "don't 
source fragment".

Joe
___
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
So I'd like to return to RFCs that have been through part of this 
discussion before,


(1) I think we need a parameter returned to the App that is equivalent 
to Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how 
many bytes the app can send with reasonable chance of unfragmented delivery.


(2) It's helpful for Apps to be able to retrieve the upper size allowed 
with potential fragmentation - that could be useful in determinine probe 
sizes for an application.  Apps should know the hard limt, In DCCP this 
is called the current congestion control maximum packet size (CCMPS), 
the largest permitted by the stack using the current congestion control 
method. That's bound to be less than or equal to what is permitted for 
the local Interface MTU. This limit lets the App also take into 
consideration other size constraints in the stack below the API.


(3) Apps need to be allowed to fragment datagrams more than MPS - This 
is not expected as the default, the stack needs to be told.


(4) Apps need to be allowed to not allow datagram fragmentation - The 
stack needs to be told. You could do this by using the DF semantics 
(i.e., don't source fragment a DF-marked packet). Thinking more, this 
seems the easiest.


Sorry, if this goes over what I said before, but I think we should first 
explore the approaches that have already been put forward in RFCs 
(alebit these were not RFCs about UDP).


Gorry


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

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

On 12/12/2016 18:50, Joe Touch wrote:



On 12/12/2016 3:45 AM, Gorry Fairhurst wrote:


So what does that mean: that the API should contain a "don't
fragment" flag from the application?


Definitely.

The use of DF in a datagram protocol is per-datagram decision -
depending on what the app needs to happen.

gorry


IMO, the app should never need to play with DF. It needs to know what it
thinks the transport can deliver - which might include transport
frag/reassembly and network frag/reassembly.

How does the App handle probes for path MTU then in UDP?

Gorry


Joe




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

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

On 12/12/2016 09:31, Michael Welzl wrote:

Hi,

Just trying to understand, so we're not talking past each other. Please note 
that I'm not trying to argue in any direction with my comments below, just 
asking for clarification:



On 09 Dec 2016, at 18:32, Joe Touch  wrote:



On 12/9/2016 8:12 AM, Michael Welzl wrote:

On 09 Dec 2016, at 16:18, Joe Touch  wrote:



On 12/9/2016 12:09 AM, Michael Welzl wrote:

On 07 Dec 2016, at 20:29, Joe Touch  wrote:

FYI, there are two different "largest messages" at the transport layer:

1) the size of the message that CAN be delivered at all

True... I wasn't thinking of that, but yes.



2) the size of the message that can be delivered without network-layer
fragmentation (there are no guarantees about link-layer - see ATM or the
recent discussion on tunnel MTUs on INTAREA)

MTU generally refers to the *link payload*. At that point, transports
have to account for network headers, network options, transport headers,
and transport options too. See RFC6691.

MSS refers to the transport message size AFAICT. It is *sometimes* tuned
to MTU-headers but not always.

E.g., for IPv6, link MTU is required to be at least 1280, but the
src-dst transit MTU is required to be at least 1500. So a transport that
wants to match sizes and reduce fragmentation issues would pick
1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time.

So I'm getting the impression that the answer to my question really is that, to 
figure out 2)  (which I was concerned with), an application programmer needs to 
do the calculation her/himself.

To figure out 2), the transport layer needs to know the unfragmented
link MTU, the size of all of the network headers (including options),
and the sizes of its own headers and options.

It's also sometimes assumes that the transport can control the "DF" bit
(for IPv4).

Yes - but that hardly sounds worse to me than requiring the application 
programmer to do this protocol-specific calculation by hand...


The app programmer needs to know what the transport can support, the
transport needs to know what net supports, etc.

Pushing the link MTU up the line and expecting all the other layers to
figure out what to do results in unnecessary complexity, never mind
undermining one of the key features of layering.


Either we just agree here, or you're saying that your 2) above should not be 
exposed? Or something else?



However, this all breaks down if the app makes the wrong choice because
the net can (will, and should) source fragment if it gets a message that
turns out  to be too big for one fragment anyway.


Not a big deal - and maybe some systems offer a function to give you the size 
of a message that won't be fragmented.

Remember that - at best - you're optimizing for the next layer down
only. You can't know whether that net layer message is link fragmented
(e.g., as in ATM) or tunnel fragmented (as needs to be required or this
whole MTU concept breaks down).

Sure - but that's something end systems just can't see. It's information up to 
and including the IP layer that should be correctly handed over up the stack, 
inside the host, with all the caveats this information comes with.

Why does that apply at the link layer but not other layers? If transport
can transfer and reassemble 1MB messages, then that's the "MTU" it needs
to tell the app layer. The same is true for net to tell transport, etc.

We've conflated the two between transport and net unnecessarily.


So this sounds like you're saying that your item 2) above should not be exposed 
by the transport layer to the application.



However: this calculation is transport protocol dependent, which we really 
don't want to have in TAPS.

If you want to fix this, you need to change the API to the net layer to
provide immediate feedback. When transport hands a segment to network,
it has to get a "call failed" if the message is too big - and we really
do need transport layers to be able to pick between "too big for
non-fragmented net layer" and "too big for the net layer even with frag".

Merely handing info to the transport layer might not be enough, esp.
when net layer option lengths change.

True if you want to cleanly fix it across the RFC-specified stack, but that's 
beyond the concern of TAPS - it becomes a requirement from the TAPS WG. Does 
that make sense?


Then this is part of the API requirements that TAPS should be
indicating, no?


So what does that mean: that the API should contain a "don't fragment" flag 
from the application?


Definitely.

The use of DF in a datagram protocol is per-datagram decision - 
depending on what the app needs to happen.


gorry



Cheers,
Michael

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



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

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

On 09/12/2016 08:09, Michael Welzl wrote:

On 07 Dec 2016, at 20:29, Joe Touch  wrote:

FYI, there are two different "largest messages" at the transport layer:

1) the size of the message that CAN be delivered at all

True... I wasn't thinking of that, but yes.



2) the size of the message that can be delivered without network-layer
fragmentation (there are no guarantees about link-layer - see ATM or the
recent discussion on tunnel MTUs on INTAREA)

MTU generally refers to the *link payload*. At that point, transports
have to account for network headers, network options, transport headers,
and transport options too. See RFC6691.

MSS refers to the transport message size AFAICT. It is *sometimes* tuned
to MTU-headers but not always.

E.g., for IPv6, link MTU is required to be at least 1280, but the
src-dst transit MTU is required to be at least 1500. So a transport that
wants to match sizes and reduce fragmentation issues would pick
1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time.

So I'm getting the impression that the answer to my question really is that, to 
figure out 2)  (which I was concerned with), an application programmer needs to 
do the calculation her/himself.
Not a big deal - and maybe some systems offer a function to give you the size 
of a message that won't be fragmented.

However: this calculation is transport protocol dependent, which we really 
don't want to have in TAPS.

I conclude: a TAPS system must implement a local function to provide this 
information, both 1) and 2) above.

Referning back to DCCP as a RFC reference which agrees with this.

I agree with (2) for a datagram transport, similar to MPS in DCCP. If 
you are going to allow different transports to be selected by TAPS - 
it's hard to know even if the transport below the TAPS API will finally 
need to choose to add an option to satisfy the service (e.g., timestamp, 
checksum, whatever ) and the size of such an option likely varies 
depending on the finally chosen protocol. To me, this suggests it useful 
to know how many bytes the app can send with reasonable chance of 
unfragmented delivery.


Apps should be allowed to send more if they wish, If an app is doing 
datagram path MTU discovery, this may resilt in raising the maximum 
unfragmented datagram size.


I'm OK with being able to retrieve the absolute maximum allowed - that 
could be useful in determinine probe sizes for an application doing path 
MTU discovery.  In DCCP there is  a hard limt, called the current 
congestion control maximum packet size (CCMPS), the largest permitted by 
the stack using the current congestion control method. That's bound to 
be less than or equal to what is permittd for the local Interface MTU.


Gorry

Cheers,
Michael

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


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

Re: [Taps] MTU / equivalent at the transport layer

[Gorry Fairhurst]

Not quoite answering this question, but for DCCP this is clearly also a 
transport understanding of the maxmium datagram size, as in RFC 4340:


"A DCCP implementation MUST maintain the maximum packet size (MPS) 
allowed for each active DCCP session."

and
"The MPS reported to the application SHOULD be influenced by the size 
expected to be required for DCCP headers and options."


Gorry

On 07/12/2016 14:54, Michael Welzl wrote:

Hi all,

I have a problem with one particular primitive, or lack of it, in UDP, UDP-Lite 
and SCTP. It's something I just don't get.

Consider this text from draft-fairhurst-taps-transports-usage-udp:

"GET_INTERFACE_MTU:  The GET_INTERFACE_MTU function a network-layer
  function that indicates the largest unfragmented IP packet that
  may be sent."

Indeed, this is a network-layer function. It's about the interface, not about 
UDP. Does that mean that, to decide how many bytes fit in the payload of a 
packet, the programmer needs to know if it's IPv4 or IPv6, with or without 
options, and do the calculation?
If so, isn't it extremely odd that UDP doesn't offer a primitive that provides 
a more useful number: the available space in its payload, in bytes?

I also have the same question for SCTP.  For TCP, it's obvious that the 
application shouldn't bother, but not for UDP or SCTP.
At the last meeting, knowing the MTU was mentioned as one of the needs that 
latency-critical protocols have. I understand that - but I didn't include this 
primitive in the last version of the usage draft because it is a network-layer 
primitive... now I don't know how to approach this.

Thoughts? Suggestions?

Cheers,
Michael

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



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

Re: [Taps] New Version Notification for draft-fairhurst-taps-transports-usage-udp-03.txt

[Gorry Fairhurst]

We have just submitted an updated copy of the UDP usage draft we have 
been working on in TAPS.


Specifically:

(1) It omits the text for pass 2 and 3 that we now expect to be directly 
incorporated in draft-ietf-taps-transport-usage.
Michael Welzl I think indicated that this text will be copied from rev 
-usage-udp-02.


(2) It contains small changes to the document text to allow this to be 
publsihed as a separate document. The WG discussed whether such a 
document could be adopted for publication as a pair with 
draft-ietf-taps-transport-usage.  The authors are now looking to the 
group to know if the WG would like to adopt this and then what further 
work may be needed.


Best wishes,

Tom & Gorry


On 05/10/2016 21:46, internet-dra...@ietf.org wrote:

A new version of I-D, draft-fairhurst-taps-transports-usage-udp-03.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:   draft-fairhurst-taps-transports-usage-udp
Revision:   03
Title:  Features of the User Datagram Protocol (UDP) and Lightweight 
UDP (UDP- Lite) Transport Protocols
Document date:  2016-10-05
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-fairhurst-taps-transports-usage-udp-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-fairhurst-taps-transports-usage-udp/
Htmlized:   
https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-03
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-fairhurst-taps-transports-usage-udp-03

Abstract:
This document describes how the User Datagram Protocol (UDP) and the
Lightweight User Datagram Protocol (UDP-Lite) transport protocols
expose services to applications and how an application can configure
and use the features offered by the transport service.  The document
is intended as a contribution to the Transport Services (TAPS)
working group to assist in analysis of the UDP and UDP-Lite transport
interface.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

[Taps] Going forward with draft-fairhurst-taps-transports-usage-udp-02 in TAPS?

[Gorry Fairhurst]

At the TAPS meeting in Berlin, I said the authors think that all the 
comments we knew about have been addressed by new text. I also took away 
a promise to ask about the proposed publication of this UDP/UDP-Lite 
usage draft.


My suggestion at the meeting was that the TAPS WG should adopt the 
UDP/UDP-Lite usage work (draft-fairhurst-taps-transports-usage-udp-02) 
as one of a pair of documents, with a proposal to publish in 
synchronisation with  draft-ietf-taps-transports-usage-01.


I'm thinking that if we take this approach, then we need to ensure that 
pass 3 in this second document exactly matches the format of 
draft-ietf-taps-transports-usage-01.


So, my questions this time on the list are again...
(1) Is it a good way to go forward to seek to publish a separate RFC on 
UDP/UDP-L?

(2) Does anyone now have any additional comments on the UDP or UDP-L usage?

Gorry

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

[Taps] : New Version Notification for draft-fairhurst-taps-transports-usage-udp-02.txt

[Gorry Fairhurst]

We have submitted a new version of the UDP Usage document. This 
incorporates changes to fix some details, but more importantly a set of 
changes that were motivatd by review comments for the 01 version. The 
authors hope this version now incorporates all details needed to allow 
the TAPS WG to proceed with consideration of the UDP protocol.


Comments and corrections are of course welcome,

Gorry & Tom

---

A new version of I-D, draft-fairhurst-taps-transports-usage-udp-02.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name:   draft-fairhurst-taps-transports-usage-udp
Revision:   02
Title:  Features of the User Datagram Protocol (UDP) and Lightweight 
UDP (UDP- Lite) Transport Protocols
Document date:  2016-05-26
Group:  Individual Submission
Pages:  25
URL:
https://www.ietf.org/internet-drafts/draft-fairhurst-taps-transports-usage-udp-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-fairhurst-taps-transports-usage-udp/
Htmlized:   
https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-fairhurst-taps-transports-usage-udp-02

Abstract:
   This document describes how the User Datagram Protocol (UDP) and the
   Lightweight User Datagram Protocol (UDP-Lite) transport protocols
   expose services to applications and how an application can configure
   and use the features offered by the transport service.  The document
   is intended as a contribution to the Transport Services (TAPS)
   working group to assist in analysis of the UDP and UDP-Lite transport
   interface.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

[Taps] new TAPS ID: draft-fairhurst-taps-transports-usage-udp-00

[Gorry Fairhurst]

We have just posted a new ID:

Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- 
Lite) Transport Protocols


https://datatracker.ietf.org/doc/draft-fairhurst-taps-transports-usage-udp/

This document provides input on UDP and UDP-Lite usage for the TAPS WG. 
In putting this together, we tried to stick with the rules of the WG 
usage draft, although the documentation for UDP in RFC series was more 
than a little erratic and scattered. I'd like to request time to present 
this at the BA IETF meeting, and we intend there to propose this as a 
formal contribution to develop the datagram part of 
draft-ietf-taps-transports-usage.


We would very much appreciate it if people who understand UDP could read 
and offer any comments. If there are some comments we would be happy to 
make further updates before the next meeting.


best wishes,

Gorry & Tom

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

Re: [Taps] IETF planning

[Gorry Fairhurst]

On 26/10/2015 13:46, Michael Welzl wrote:



On 26. okt. 2015, at 14.17, Aaron Falk mailto:aaron.f...@gmail.com>> wrote:

On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst mailto:go...@erg.abdn.ac.uk>> wrote:

On 22/10/2015 15:14, Aaron Falk wrote:


> draft-welzl-taps-transports currently only covers TCP
and SCTP. But then: how many other protocols?
> It seems people agree that the protocols covered in
draft-welzl-taps-transports should be a subset of the
protocols covered in draft-ietf-taps-transports. My question
is, then: how to choose the subset?
>
> It seems obvious to include protocols that are seeing
some deployment, i.e. of course UDP, maybe UDP-Lite (?), but
also MPTCP…
> However: if that is the only decision ground, we
probably wouldn’t include DCCP. Are we then making a
significant mistake, missing a lesson to be learned?
>
> That, to me, is a discussion I’d like to have in Yokohama.

+1, and FWIW that's exactly the same starting point I got
to on my own.


Any volunteers to kick off the lead the discussion?





So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.


Assuming this is a typo and you mean MPTCP, I agree.


Then we agree on this.




On DCCP, this has many services being re-invented above. I think
we have an interesting dilemma about whether to describe this, I
suggest one of the reason for the minimal use of DCCP (DCCP/UDP)
could well be the lack of a framework that allows this to be done
without recoding an app. So, if we had such a framework *WHEN*
DCCP/UDP was done, we may now have seen more usage.


I understand and agree, but that doesn’t help us now…



I don't understand.  Why leave out any of the protocols included in
draft-ietf-taps-transports?  Is there an argument other than for
expedience?


Working towards a realistic end-goal of a deployable system.

So we’re i) describing services; ii) narrowing them down somehow; iii)
describing how to build this thing.
My concern is with iii) being something feasible and useful, not an
obscure sci-fi document.

Say we include DCCP. It’ll add some services that aren’t in the other
protocols listed so far in this mail - e.g. drop notification (see
section 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we find
no good arguments to remove drop notification. Then, in step iii), we’ll
have to say how a TAPS system can support drop notification. So, to
build a working TAPS system, one has to either:
- include DCCP in the code base
- extend other protocols to provide this functionality

None of these two options are very helpful if we want to TAPS to be real
thing one day.

I understand that we can see these as optional, and end up with a
document iii) that has a small mandatory base and lots of optional
things - but this will then be a huge document, of which only a small
subset will ever be implemented. Personally I think that’s a possibility
but not really what we should aim at.

Cheers,
Michael

Yes, that discussion is probably consistent with my thinking - If we 
want to focus on what can be made right now, we can't include DCCP - not 
because it can't be done - a lot of code has been written, and we 
understand the spec - but because it's one step further-on than we 
currently can achieve easily in the first pass. (If that's the 
motivation for excluding it, I would understand at this stage.)


I think one could say the same for other protocols that could/have been 
layered over UDP. Does that also therefore mean we don't currently 
include such other protocols?


Gorry




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

Re: [Taps] IETF planning

[Gorry Fairhurst]

On 22/10/2015 15:14, Aaron Falk wrote:


> draft-welzl-taps-transports currently only covers TCP and SCTP. But then: 
how many other protocols?
> It seems people agree that the protocols covered in 
draft-welzl-taps-transports should be a subset of the protocols covered in 
draft-ietf-taps-transports. My question is, then: how to choose the subset?
>
> It seems obvious to include protocols that are seeing some deployment, 
i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP…
> However: if that is the only decision ground, we probably wouldn’t 
include DCCP. Are we then making a significant mistake, missing a lesson to be 
learned?
>
> That, to me, is a discussion I’d like to have in Yokohama.

+1, and FWIW that's exactly the same starting point I got to on my own.


Any volunteers to kick off the lead the discussion?






So, I think UDP, and UDP-Lite *NEED* to be included. MPTCOP also.

On DCCP, this has many services being re-invented above. I think we have 
an interesting dilemma about whether to describe this, I suggest one of 
the reason for the minimal use of DCCP (DCCP/UDP) could well be the lack 
of a framework that allows this to be done without recoding an app. So, 
if we had such a framework *WHEN* DCCP/UDP was done, we may now have 
seen more usage.




--aaron


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



Gorry

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

Re: [Taps] document progress update?

[Gorry Fairhurst]

I'd have thought it was worth seeing if FECFRAME fits as something to 
talk about.


It is used in places. There are transport concerns that differ and could 
be highlighted  - because some uses require pre-provisioned capacity 
(aka, do not have CC), so we probably need to say something about 
managed environments.


Whether it is a transport protocol (like TCP, UDP, websockets, etc), or 
a component (like ledbat) could be an interesting first debate.


What do others think?

Gorry

On 07/09/2015 08:29, Vincent Roca wrote:

Hello everybody,


• Vincent Roca will write something about FLUTE based on NORM


- took a quick look at this, it looks good. Vincent also sent a suggestion that 
we mention FECFRAME here, though no integration-ready text.


I can provide some FECFRAME (https://datatracker.ietf.org/doc/rfc6363/) text 
tomorrow,
Tuesday, 8th, if you’re interested. This is not a big deal, I’m just waiting 
the « go ».

IMHO FECFRAME makes sense in the TAPS approach. Unlike the NORM and FLUTE/ALC
full featured protocols, FECFRAME is a shim layer that can be dynamically 
plugged between an
application protocol (typically RTP) and a datagram oriented transport protocol 
(typically UDP).
It then provides FEC protection, using one of the various FEC schemes proposed. 
Commercial
deployments have started and several solutions are not encumbered with IPR (at 
least so far).
I can tell you more if you want.

Cheers,

   Vincent



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



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

Re: [Taps] draft minutes -- please review

[Gorry Fairhurst]

On 06/08/2015 09:50, Mirja Kühlewind wrote:

ant to mention that there are different kinds of congestion control (as it is 
already done in the doc) but there is no need to e.g. describe LEDBAT in detail.

I fixed some minor English NiTS and added this to the Etherpad version:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-taps



Gorry

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

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

[Gorry Fairhurst]

This version includes my first go at a table, in section 4.1, I'm hoping 
this will stimulate some input/corrections, or even perhaps alternate 
list of what to see here. Please discuss, or send comments via the TAPS 
list.


gorry



straw On 07/02/2015 12:41, Brian Trammell wrote:

Greetings, all,

We've submitted the -02 rev of the transports document, addressing comments to 
date and including additional content for some of the transport protocols.

Markdown (kramdown-rfc2629) source and toolchain is available at 
https://github.com/britram/taps-transports. Subsection authors: feel free to 
send pull requests against either the markdown or XML source (we'll convert the 
latter back to the former) or text to the editors via email. We'd like to get 
at least one more rev of the document out before Dallas.

Not-yet-subsection-authors who would like to contribute: there are a couple of sections 
we'd like to have (HTTP(S) as a pseudotransport, and WebSockets which removes some of the 
"pseudo" therefrom) that don't yet have contributors associated; additionally, 
if there are transport (or transport-like) protocols we're missing here, please send text 
and we'll get it integrated.

Many thanks, best regards,

Brian (for the editors of taps-transports).


Begin forwarded message:

From: internet-dra...@ietf.org
To: 
Date: 7 Feb 2015 13:07:02 CET
Cc: taps@ietf.org
Subject: [Taps] I-D Action: draft-ietf-taps-transports-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Services Working Group of the IETF.

Title   : Services provided by IETF transport protocols and 
congestion control mechanisms
Authors : Godred Fairhurst
  Brian Trammell
  Mirja Kuehlewind
Filename: draft-ietf-taps-transports-02.txt
Pages   : 20
Date: 2015-02-07

Abstract:
   This document describes services provided by existing IETF protocols
   and congestion control mechanisms.  It is designed to help
   application and network stack programmers and to inform the work of
   the IETF TAPS Working Group.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-taps-transports-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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




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



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

[Taps] Fwd: Fwd: Re: So, catching back up on the charter

[Gorry Fairhurst]

So on the Charter, as at:

https://datatracker.ietf.org/doc/charter-ietf-taps/

This is a much longer rant than I wanted, so if you read no more, the
main point is in the next para:

I think the M18 milestone (also called No 3) is well-intentioned, 
especially if targeted as an EXP RFC. To me this never was an interface 
spec, although it needs some form of communication with the App, it is 
the way you find out which protocol to use on an actual path from a set 
of protocols that may offer a service.


Spencer asked the question:

"How important is it for the working group to begin work on the third
deliverable immediately?"

My take, is it is very important that the WG has item 3 (an EXP for
certain, or even a PS!) as their "goal" and starts attracting discussion
and individual IDs that can take this topic forward - I for one, would
want to start thinking about which potential ways could solve the
problems, and to discuss these via the mailing list to try and build an
ID. Yes, there are multiple possibilities, and many pitfalls, but I'd be
fine to try writing one draft, and expect others to collaborate or find
other ideas (probably better - who knows?). As the WG proceeds, it will 
find out if methods are deployable or deplorable - just as mptcp did for 
their protocol, and we could then decide to move forward or even give-up.


Adopting a specific draft early is maybe not so critical at the start,
(and that would be really OK), but I think there needs to be a clear aim
towards finding the mechanisms and identify issues. This is not an easy
topic to bring together, it's worth the work though!!!

What options are there?

--- I think with a Charter that allows this, and possibly milestone for
this topic, the group has a clear goal. The status needs to be EXP,
well a good AD will generally tell the WG if they don't achieve this
level of quality.  Starting as non-EXP and, upgrading the status later
to EXP or expecting to publish as non-WG but widely used RFC seems to me
to be the wrong initial starting point. I personally do not see a
conflict with this activity and any other current IETF activity, so why
the hesitation here?

--- If people really see  Charter text that said there can be no such 
milestone, somehow this forces the group to prepare a "problem 
statement", which although isn't bad, also isn't really the end-goal If 
the protocol work needs a recharter, it punts and delays the decision to 
sometime later - at the first two TAPS meetings there were many 
researchers and people from industry around, all saying things, in 
general I observe at the IETF: the longer we punt, the less wide the 
contributions.


So, I suggest:

* Ensure the Charter permits the 3rd milestone (and if necessary try to 
set some bounds to what it will say).


Setting a restriction that requires the IESG to approve a new Charter to
decide whether an EXP transport protocol can be published seems
s like a "wait-and-we-decide-later" tactic to me. That's bad for
the WG. And then, if our IETF process were to fail to sort this out 
promptly, as-it-seems-it-may, I expect requests from the WG individual 
draft authors to still progress this discussion and design using IDs and 
the WG mailing lists and meetings (albeit with less visibility tha 
having a WG milestone) and then to request to publish something.  If the 
charter forbids this, then a request to publish as independent 
submission to become some sort of less-reviewed de-facto "experimental 
RFC"... I don't see why we would do this.


Hope this is helpful, and people will be joining in this exciting and
hopefully useful venture!

Gorry

NiTS remaining:

/Specify the subset of those Transport Services, as identified in
  item 1, /
- I'd remove this and other very specific references to the milestone
numbers, when published, the AD may adjust milestones, and this doesn't
to me seem to have to redo the charter text.

/The Working Group deliverables will help an application/
programmers
- mixer singular and plural /programmers/programmer/

Bullet:
/Quality-of-Service (QoS) and tunneling mechanisms and services/
I think should be
/definition of new Quality-of-Service (QoS) mechanisms/
- to align with other bullets.






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