> On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <anna.brunst...@kau.se> wrote: > > Hi Joe, > > Thanks for your comments! > On 2017-03-21 23:41, Joe Touch wrote: >> Hi, all, >> >> Some observations: >> >> - HE-trans MUST NOT be used to try different combinations of options within >> a given transport >> > > Sounds reasonable, trying out options is not the target here. Not sure if > options even need to be discussed in the draft. > >> - I'm wondering about the potential for problems when ports are reused >> between different attempts, e.g., IPv6-TCP then IPv4-TCP > > This should be the same as for RFC6555, so I do not think any new problems in > relation to port reuse are introduced. > >> - the document works only for connection-orient transports that treat failed >> connections as "no information" >> >> if a connection fails for other reasons, the origin might receive an >> ICMP message that prohibits further attempts, either to that transport, >> port, or address >> >> if a connection attempt is rejected but used as information, you could >> end up with confusing results (e.g., as a covert channel) >> in that case, you're not doing HE; IMO, HE requires that there be no >> impact to failed attempts >> > > I do not follow this argument. Why does HE require that there be no impact to > failed attempts? I think caching of failed connection attempts is important > to reduce network load. RFC6555 also requires that the client MUST cache > information regarding the outcome of each connection attempt, so the same > principle should be followed here I think.
I think there are two separate cases here: - If the client that is initiating the protocol attempts is using a protocol for which a failed attempt causes it to throw an error/exception, then the act of racing will have a negative impact on the client. - If, instead, the client simply uses the failed attempt as historical information to inform future policy, then that is very much in line with RFC 6555, Section 4.2 It would be useful to clarify in the document that the only protocols which can be meaningfully raced via any mechanism are those that have a notion of becoming "connected" or "established" that does not correspond to simply sending the first bit of data. UDP and traditionally 'connectionless' protocols can have some overlay of what it means to be 'connected' to cut off the race, or else they form the degenerate case in which the race it cut off immediately once a connection attempt is started. Thanks, Tommy > > Thanks again for your comments, > Anna > >> Joe >> >> On 3/14/2017 2:37 AM, Anna Brunstrom wrote: >>> Hi all, >>> >>> The draft below on happy eyeballs was submitted last night. It is on the >>> agenda for Chicago, but we are happy to hear any comments you may have also >>> before then. >>> Cheers, >>> Anna >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-grinnemo-taps-he-02.txt >>> Date: Mon, 13 Mar 2017 11:18:59 -0700 >>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> >>> To: Zdravko Bozakov <zdravko.boza...@dell.com> >>> <mailto:zdravko.boza...@dell.com>, Zdravko Bozakov >>> <zdravko.boza...@dell.com> <mailto:zdravko.boza...@dell.com>, Anna >>> Brunstrom <anna.brunst...@kau.se> <mailto:anna.brunst...@kau.se>, Per >>> Hurtig <per.hur...@kau.se> <mailto:per.hur...@kau.se>, Karl-Johan Grinnemo >>> <karl-johan.grinn...@kau.se> <mailto:karl-johan.grinn...@kau.se>, Naeem >>> Khademi <nae...@ifi.uio.no> <mailto:nae...@ifi.uio.no> >>> >>> A new version of I-D, draft-grinnemo-taps-he-02.txt >>> has been successfully submitted by Karl-Johan Grinnemo and posted to the >>> IETF repository. >>> >>> Name: draft-grinnemo-taps-he >>> Revision: 02 >>> Title: Happy Eyeballs for Transport Selection >>> Document date: 2017-03-13 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt >>> <https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt> >>> Status: https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ >>> <https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/> >>> Htmlized: https://tools.ietf.org/html/draft-grinnemo-taps-he-02 >>> <https://tools.ietf.org/html/draft-grinnemo-taps-he-02> >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02 >>> <https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02> >>> >>> Abstract: >>> Ideally, network applications should be able to select an appropriate >>> transport solution from among available transport solutions. >>> However, at present, there is no agreed-upon way to do this. In >>> fact, there is not even an agreed-upon way for a source end host to >>> determine if there is support for a particular transport along a >>> network path. This draft addresses these issues, by proposing a >>> Happy Eyeballs framework. The proposed Happy Eyeballs framework >>> enables the selection of a transport solution that according to >>> application requirements, pre-set policies, and estimated network >>> conditions is the most appropriate one. Additionally, the proposed >>> framework makes it possible for an application to find out whether a >>> particular transport is supported along a network connection towards >>> a specific destination or not. >>> >>> >>> >>> >>> >>> 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 <mailto:Taps@ietf.org> >>> https://www.ietf.org/mailman/listinfo/taps >>> <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
