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

Anna Brunstrom <anna.brunstrom@kau.se> Mon, 27 March 2017 23:36 UTC

Return-Path: <prvs=02591274b3=anna.brunstrom@kau.se>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07D1295E3 for <taps@ietfa.amsl.com>; Mon, 27 Mar 2017 16:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMc-HEtncmuc for <taps@ietfa.amsl.com>; Mon, 27 Mar 2017 16:36:00 -0700 (PDT)
Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CDA12963D for <taps@ietf.org>; Mon, 27 Mar 2017 16:35:57 -0700 (PDT)
X-Spam-Processed: mail.kau.se, Tue, 28 Mar 2017 01:35:49 +0200 (not processed: spam filter heuristic analysis disabled)
X-MDRemoteIP: 213.113.182.104
X-MDArrival-Date: Tue, 28 Mar 2017 01:35:49 +0200
X-Authenticated-Sender: anna.brunstrom@kau.se
X-Return-Path: anna.brunstrom@kau.se
X-Envelope-From: anna.brunstrom@kau.se
To: Joe Touch <touch@isi.edu>, "taps@ietf.org" <taps@ietf.org>
References: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu>
From: Anna Brunstrom <anna.brunstrom@kau.se>
Message-ID: <c24794e2-3c81-2e52-89a4-e27148e4a007@kau.se>
Date: Tue, 28 Mar 2017 01:35:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu>
Content-Type: multipart/alternative; boundary="------------290BFF97F0CFD81D500213AE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/t7LZcEhgivQOUpQfW2JuD-2YbLA>
Subject: Re: [Taps] Fwd: New Version Notification for draft-grinnemo-taps-he-02.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 23:36:03 -0000

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.

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: 	internet-drafts@ietf.org
>> To: 	Zdravko Bozakov <Zdravko.Bozakov@dell.com>, Zdravko Bozakov 
>> <zdravko.bozakov@dell.com>, Anna Brunstrom <anna.brunstrom@kau.se>, 
>> Per Hurtig <per.hurtig@kau.se>, Karl-Johan Grinnemo 
>> <karl-johan.grinnemo@kau.se>, Naeem Khademi <naeemk@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
>