Subject: [Taps] Fwd: New Version Notification for draft-grinnemo-taps-he-02.txt

From: Anna Brunstrom <[email-masked]>
Date: Tue, 14 Mar 2017 10:37:44 +0100

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-masked]
To: 	Zdravko Bozakov <[email-masked]>, Zdravko Bozakov 
<[email-masked]>, Anna Brunstrom <[email-masked]>, Per 
Hurtig <[email-masked]>, Karl-Johan Grinnemo 
<[email-masked]>, Naeem Khademi <[email-masked]>

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Mar 2017 15:41:27 -0700

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

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 28 Mar 2017 01:35:47 +0200

Hi Joe,

Thanks for your comments!

> - HE-trans MUST NOT be used to try different combinations of options 

Sounds reasonable, trying out options is not the target here. Not sure 
if options even need to be discussed in the draft.

> 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.

>     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
>
>     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.

Thanks again for your comments,
Anna

>> 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:

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 27 Mar 2017 22:45:55 -0500

> On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <[email-masked]> wrote:
> 
> Hi Joe,
> 
>> - 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

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

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 28 Mar 2017 08:40:38 +0200

Hi Tommy,

On 2017-03-28 05:45, Tommy Pauly wrote:

>
>> On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Joe,
>>
>> 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 
>>
>>> - 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
>>>
>> 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.
>
> - 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

>>>> 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
>>>>
>>>> until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>