Hi, all, Some observations:
- HE-trans MUST NOT be used to try different combinations of options within a given transport - I'm wondering about the potential for problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP - 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 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 > To: Zdravko Bozakov <zdravko.boza...@dell.com>, Zdravko Bozakov > <zdravko.boza...@dell.com>, Anna Brunstrom <anna.brunst...@kau.se>, > Per Hurtig <per.hur...@kau.se>, Karl-Johan Grinnemo > <karl-johan.grinn...@kau.se>, Naeem Khademi <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 > Status: https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ > Htmlized: https://tools.ietf.org/html/draft-grinnemo-taps-he-02 > Diff: 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 > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps