[Taps] review: draft-grinnemo-taps-he-02

"Bajpai, Vaibhav" <vaibhav.bajpai@tum.de> Tue, 18 April 2017 14:20 UTC

Return-Path: <vaibhav.bajpai@tum.de>
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 AD3281318B9 for <taps@ietfa.amsl.com>; Tue, 18 Apr 2017 07:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de
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 CEmmCjnavJwH for <taps@ietfa.amsl.com>; Tue, 18 Apr 2017 07:20:21 -0700 (PDT)
Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (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 0248C12F17A for <taps@ietf.org>; Tue, 18 Apr 2017 07:20:21 -0700 (PDT)
Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 3w6nN25LpBzyTf for <taps@ietf.org>; Tue, 18 Apr 2017 16:20:18 +0200 (CEST)
Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-transfer-encoding:content-id:content-type :content-type:content-language:accept-language:message-id:date :date:subject:subject:from:from:received:received:received :received; s=postout; t=1492525217; bh=tlVMIvYdwalqgvbYvmfmIY1sk 2CcNdEen2TMc0ov5DQ=; b=aUgde3X5s5LZFcoNupTfYR/tsRGVNlvCgnIWePZ6i 9OJewcDRoY55hd/NBDi63I7blrhS/nlvRdQbdNxQlMLhzyrQHPcgowBVicQelyu9 WczmlX+HL3hzxQp+ezjFCDf2N1dZ9S4UFg59d71ScH6iG2nYkU0tiY2Nfh3wmf2/ vfNZwU6O6+3U8dPr5NKyK1yQmbJk9EmDlX+W8IRejPwv9xapQPGTXzayO3kVVAmj FVWAIlM/2jJLHK5o1YNLPEcOr5NAsvz+mYlFz0+sOL4HRIQFKNJ9lN9EP4yTm0YU DpCal8FEERhQHHVmsiwBLrIo9dBlxBNaC62jzagVQZXsg==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de
Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 53nIbPdTwOFw for <taps@ietf.org>; Tue, 18 Apr 2017 16:20:17 +0200 (CEST)
Received: from BADWLRZ-SWMBX05.ads.mwn.de (unknown [IPv6:2001:4ca0:0:108::161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX05", Issuer "BADWLRZ-SWMBX05" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 3w6nN16hw7zySb for <taps@ietf.org>; Tue, 18 Apr 2017 16:20:17 +0200 (CEST)
Received: from BADWLRZ-SWMBX02.ads.mwn.de (2001:4ca0:0:108::158) by BADWLRZ-SWMBX05.ads.mwn.de (2001:4ca0:0:108::161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32; Tue, 18 Apr 2017 16:20:12 +0200
Received: from BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b]) by BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b%14]) with mapi id 15.01.0669.032; Tue, 18 Apr 2017 16:20:12 +0200
From: "Bajpai, Vaibhav" <vaibhav.bajpai@tum.de>
To: "taps@ietf.org" <taps@ietf.org>
CC: "Bajpai, Vaibhav" <vaibhav.bajpai@tum.de>
Thread-Topic: review: draft-grinnemo-taps-he-02
Thread-Index: AQHSuE7kyIpfpltlPUWzq2nLmLE6GA==
Date: Tue, 18 Apr 2017 14:20:12 +0000
Message-ID: <15976658-97f5-4080-a332-f539648b4b6e@BADWLRZ-SWMBX05.ads.mwn.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [131.159.24.54]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <37A8007A80FC684684AB2FEB4CF4A439@ads.mwn.de>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/1HeaPxntLX9YHCtq9K8ckwj7dzk>
Subject: [Taps] review: draft-grinnemo-taps-he-02
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: Tue, 18 Apr 2017 14:20:24 -0000

>   Title:	  Happy Eyeballs for Transport Selection
>   URL:            https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt

Overall, I like this document (suggestions for improvements below). I hope an
HE mechanism helps get future transport protocols get wider adoption.

-- Vaibhav


  To be compliant with RFC 6555 [RFC6555], the Policy Management component
  SHOULD, in those cases there are no policies telling otherwise, give priority
  to IPv6 over IPv4.

-- RFC 6555 does not give priority to v6. Yes, this was the original
motivation for the document, but RFC 6555 states that the priority is dictated
by the address selection policy [RFC 6724]. In majority of the scenarios this
boils down to giving priority to native v6. However, if a host has native v4
and Teredo connectivity, a HE implementation will happily give priority to
native v4 over Teredo.



  To minimize the number of connection attempts that are initiated,
  the Transport Probing component SHOULD cache the outcome of
  connection attempts in a repository kept by the Policy Management
  component.

  Cached connection-attempt results SHOULD be valid for a configurable
  amount of time after which they SHOULD expire and have to be repeated.

-- How long should this cache be? How is this configured?


  D then governs the delay between the initiation of the connection
  attempts C1 and C2.

-- how is delay D determined?




  For the Transport Probing component to be able to efficiently use the
  connection-attempt cache, already-initiated, non-winning transport solutions
  SHOULD NOT be terminated as soon as a winning connection has been established.

-- I found this sentence confusing. Perhaps an example helps here.


  As pointed out in RFC 6555 [RFC6555], a HE algorithm should not waste
  networking resources by routinely making simultaneous connection
  attempts.  To this end, the HE algorithm should cache the outcome of
  previous connection attempts to the same peer.  The impact and
  efficiency of the HE algorithm has been evaluated in
  [Papastergiou16].  The paper suggests that caching significantly
  reduces the CPU load imposed by a HE mechanism.


-- Perhaps make it clear that [Papastergiou16] discusses the impact of memory
   and cpu resources on the end-host and not networking resources on the wire.



  Consider a scenario in which an IPv4-only client using the ...

-- Why not v6-only client instead? :)



-- It was unclear to me how the the list of candidate protocols is generated
   by the policy manager. An example would help here. I am even thinking
   perhaps this is out of scope of this document.


--------------------------
Vaibhav Bajpai
www.vaibhavbajpai.com

Postdoctoral Researcher
TU Munich, Germany
--------------------------