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: [email protected]
> To: Zdravko Bozakov <[email protected]>, Zdravko Bozakov
> <[email protected]>, Anna Brunstrom <[email protected]>,
> Per Hurtig <[email protected]>, Karl-Johan Grinnemo
> <[email protected]>, Naeem Khademi <[email protected]>
>
>
>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
