Hi Tommy,
On 2017-03-28 05:45, Tommy Pauly wrote:
On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <[email protected]
<mailto:[email protected]>> 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
Agreed. We will try to clarify this in the next version of the document.
Thanks for your feedback!
Anna
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: [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 attools.ietf.org
<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
