Re: [lisp] Some questions about draft-kouvelas-lisp-reliable-transport-00

Isidoros Kouvelas <kouvelas@cisco.com> Tue, 04 March 2014 16:41 UTC

Return-Path: <kouvelas@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934F91A0191 for <lisp@ietfa.amsl.com>; Tue, 4 Mar 2014 08:41:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level:
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 yjU4BPLhZYKX for <lisp@ietfa.amsl.com>; Tue, 4 Mar 2014 08:41:46 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id E3C681A01A8 for <lisp@ietf.org>; Tue, 4 Mar 2014 08:41:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3641; q=dns/txt; s=iport; t=1393951303; x=1395160903; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KfSLi8zKsJwu4tMIrYoCIFDlAOZ/ZTOF2dOpUHgWrbE=; b=P4CdAJZ3p19YlCJdIQjhxz9tC+cTh82JIARP4BoTgvEcE4TavgCw4OaF zKLJ0144KucJHBurDeKwDV5GNa4A/RViIohP2s99p9HEZiVOTL2KNwny1 k8URAyt4J4CdK7Lfwa+4yO22oVw5VOt2FHPqcI2tzQoSRKQCX5E7Vy5Yq 8=;
X-IronPort-AV: E=Sophos;i="4.97,585,1389744000"; d="scan'208";a="2377846"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 04 Mar 2014 16:41:42 +0000
Received: from dhcp-10-61-106-71.cisco.com (dhcp-10-61-106-71.cisco.com [10.61.106.71]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s24Gfdkg012873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 16:41:41 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Isidoros Kouvelas <kouvelas@cisco.com>
In-Reply-To: <20140303180104006703.80a87a81@sniff.de>
Date: Tue, 4 Mar 2014 18:41:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DD09DE8-4230-4515-9123-822979A50A3C@cisco.com>
References: <20140303180104006703.80a87a81@sniff.de>
To: Marc Binderberger <marc@sniff.de>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/KBWkfKmNS_vhEICh-atV_I-lM4U
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Some questions about draft-kouvelas-lisp-reliable-transport-00
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 16:41:48 -0000

Marc,

Thanks for the comments. Inline…

On Mar 4, 2014, at 4:01, Marc Binderberger <marc@sniff.de> wrote:

> Hello LISP experts, hello Isidoros/Christian/Darrel,
> 
> had a quick look at your draft - and now I have some questions.
> 
> 
> You make the statement that your proposal avoids the load problem of 
> periodic registration and processing. But I wonder if you simply move 
> the problem out of the LISP domain. What do I mean:
> 
> protocols like BGP and LDP use explicit KeepAlive messages on the TCP 
> session. The rationale is (from the LDP and BGP RFCs):
> 
>  LDP uses the regular receipt of LDP PDUs on the session transport
>  connection to monitor the integrity of the session.
> 
>  KEEPALIVE messages may be sent periodically to ensure that the
>  connection is live.
> 
> Have there been improvements in TCP implementations that make such 
> checks unnecessary today?
> 
> 
> My guess is what you can achieve is reducing per-EID refresh/timeout 
> with a per-session or per-xTR timeout (?). Which is no small 
> achievement. But your statement goes further - and I don't fully buy 
> into it :-)

We have two different requirements. One is to be able to communicate EID to RLOC registrations the other is to be able to detect session liveness. The periodic UDP registrations cover both as if the MS reloads the next periodic registration will rebuild the MS state. With the reliable transport what we are doing is eliminating the periodic overhead of EID registrations. You are correct that some periodic processing is still necessary for liveness purposes (either at the TCP level or through keep-alives on top of the session). The benefit is that the keep-alive is now independent of the EID prefix scale.

> Another statement in your draft says
> 
>                                    The use of the reliable transport
>  session for EID prefix registration is an alternative and does not
>  replace the existing UDP based mechanism.
> 
> Okay, you describe the coexistence of periodic and stateful in section 
> 6.2 but the question I have is: is this wise to mix a soft-state and a 
> stateful protocol definition?  I'm not arguing in favour for one of 
> them but it seems a duplication of work to implement both. Which again 
> is fine for some interim period if you plan to morph LISP from soft 
> state to hard state (?). But that's not what you state.
> 
> So I wonder if splitting this into at least two orthogonal aspects was 
> considered: (1) replacing the UDP socket with a TCP socket to allow 
> large updates and get PMTU discovery, retransmit etc. for free, solving 
> the reliability for large EID updates. And (2) per-xTR keepalive to 
> address large scale problems on the map server. That is large scale 
> either in EID prefixes and/or large number of xTRs.
> This would keep the soft state at the core but add improvements.
> 
> Again, just wonder if this was discussed and if so what made the 
> decision to go for an additional hard-state implementation?

Maintaining compatibility with existing code and keeping the barrier for new implementations low is significant. There are also several use cases with a small number of EID prefixes per xTR that can still work perfectly well with the existing UDP based registration model. For example mobile node would never have more than a single EID prefix and the changing RLOC would complicate reliable transport session maintenance.

thanks
Isidor