Draft: draft-trammell-taps-interface

Commentary: Added text about what happens when an application specifies both protocol and path selection properties . Path selection properties have precedence . I examples to both API and implementation draft to illustrate this . Relates to 
 In section 5.2 . in the API doc : " Internally , the transport system will first exclude all protocols and paths that match a Prohibit , then exclude all protocols and paths that do not match a Require , then sort candidates according to Preferred properties , and then use Avoided properties as a tiebreaker . Selection Properties that select paths take preference over those that select protocols . For example , if an application indicates a preference for a specific path by specifying an interface , but also a preference for a protocol not available on this path , the transport system will try the path first , ignoring the preference . " This sounds rather like an example algorithm that should maybe go into the implementation doc instead ? Or is there any part of this that we need to specify normatively in order to ensure that all systems implement the same ? 
 This goes back to issue on " conflicting policies " . At the time , we decided that there must be a deterministic outcome , therefore , text was to both the API and the Implementation document , see . If we keep it that way , perhaps the text here should point out that the goal is to resolve conflicting policies , so we achieve a deterministic outcome . 
 Ah okay , thanks for the background info ; missed that . I think we need to use normative language here then . Maybe also a separate subsection makes this more prominent . 
 This reads to me like the rules for processing polices rather than an example algorithm . I think it is part of the API ... Normative language would be good and a stronger opening that explains why the rules exist . 
 I do n't think a separate subsection would make this a better read - this fits fine as it stands , as an intro to the transport property specification IMO . Regarding normative language , that 's a separate discussion . So , can we close this issue ? 
 Agree that we do n't need a separate subsection . I can try to tweak the beginning of this part a bit to explain why the rules exist as suggested . Regarding normative language - we definitely have it in the API draft , right ? So why not have the discussion on it here as well ? if we 're serious about deterministic outcomes , I guess the whole thing needs to be a MUST , right ? 
 Sorry , true , that normative language debate was about the arch draft , and we definitely have it in the API draft . So yes , let 's discuss it here . I also think a MUST would make sense . 
 So the order of filtering out require / prohibit is not important ( outcome is the same ) - making the order a MUST does not make sense . Also , first sorting by preference and then filtering has the same outcome as doing it the other way around . the only thing we need to say is that filtering MUST happen and sorting SHOULD happen . 
 ok - I have to admit I did n't think this through , I just agree that we want a deterministic outcome from this . 
 Why did we require a deterministic behavior in first place ? Does this prevent TAPS implementations from running experiments like Apple did with TCP SACK and ECN ? Does this prevent probabilistic path probing ? 
 This was discussed in the TAPS BoF ? ... I thought it was about developers being assured that X will happen if they choose Y and not finding the ground shifting as they use the interface . 
 Interim : Prefers and avoids allow the implementation to decide the ordering and weighting ; require and prohibit are the only hard requirements . Applications should be able to cope with any possibility that is n't prohibited . Likely should add implementation text to say how preferences weight racing . 
 During the interim discussion , we found that was too strict and limiting , so we opted for another approach that moves the selection algorithm to the Implementation draft . I 'm preparing another PR implementing these changes . 
 The text that ended up in the implementation draft is not fully consistent with the racing text , opening a new issue for this and closing this issue . 
 See thread at Suggested resolution : implementation must have a deterministic tiebreaker , current recommendation is that path properties take precedence . API should note expected behavior . There should be additional text on candidate selection and ordering . 
 Give example for path candidate gathering and sorting ( get selection properties , get available paths in system preferred order , walk through them cancelling out the prohibited ones , and ranking preferences ; get ultimate list ) . Do the same for protocols likely . 
 Added text to API and Implementation drafts on branch " conflicting - policies " . API has an example , implementation still needs one . Feel free to add , otherwise I 'll come back to it later today or tomorrow . 
 I guess that works for -00 For -01 , we might want to integrate the resolution a little bit more into the decision process . 
 Resolved by PR 
 this is good , thanks !
Mailing list commentary: Hi , I made this comment in the past in QUIC when discussing migration . One policy may be prefer wifi over cellular network , Second policy prefers quic cove TCP Now I walk into my house and my cellphone has HTTP over QUIC . At home will switch to wifi but quic is not supported on the wifi so will fall back to TCP . This contradicts the second policy . So two options wifi TCP or cellular QUIC , how to decide ?
Paragraph (version B):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then only keep candidates that match a
Require, then sort candidates according to Preferred properties, and
then use Avoided properties as a tiebreaker.  In case of conflicts
between protocol and path selection properties, path selection
properties take precedence.  For example, if an application indicates
a preference for a specific path, but also a preference for a
protocol not available on this path, the transport system will try
the path first, so the protocol selection property might not have an
effect.
Paragraph (version B):
Implementations should sort the branches of the tree of connection
options in order of their preference rank.  Leaf nodes on branches
with higher rankings represent connection attempts that will be raced
first.  Implementations should order the branches to reflect the
preferences expressed by the application for its new connection,
including Protocol and Path Selection Properties, which are specified
in I-D.trammell-taps-interface.
Paragraph (version B):
Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid.  If Protocol or Path Selection
Properties contain any prohibited properties, the implementation
should first purge branches containing nodes with these properties.
For required properties, it should only keep branches that satisfy
these requirements.  Finally, it should order branches according to
preferred properties, and finally use avoided properties as a
tiebreaker.
Paragraph (version B):
For Require and Avoid, Path Selection Properties take precedence over
Protocol Selection Properties.  For example, if the application has
indicated both a preference for WiFi over LTE and for a feature only
available in SCTP, branches will be first sorted accord to the Path
Selection Property, with WiFi at the top.  Then, branches with SCTP
will be sorted to the top within their subtree according to the
Protocol Selection Property.  However, if the implementation has
cached the information that SCTP is not available on the path over
WiFi, there is no SCTP node in the WiFi subtree.  Here, the path over
WiFi will be tried first, and, if connection establishment succeeds,
TCP will be used.  So the Path Selection Property of preferring WiFi
takes precedence over the Protocol Selection Property of preferring
SCTP.