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

[Anna Brunstrom <[e-mail]>]

Hi Tommy,


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

>
>> On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <[e-mail] 
>> <mailto:[e-mail]>> 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: 	[e-mail]
>>>> To: 	Zdravko Bozakov <[e-mail]>, Zdravko Bozakov 
>>>> <[e-mail]>, Anna Brunstrom <[e-mail]>, 
>>>> Per Hurtig <[e-mail]>, Karl-Johan Grinnemo 
>>>> <[e-mail]>, Naeem Khademi <[e-mail]>
>>>>
>>>>
>>>>
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/taps
>>>
>>
>> _______________________________________________
>> Taps mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/taps
>