Re: [homenet] Updates to Homenet Architecture Principles doc

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Sat, 14 June 2014 15:49 UTC

Return-Path: <jch@pps.univ-paris-diderot.fr>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17491B2C2F for <homenet@ietfa.amsl.com>; Sat, 14 Jun 2014 08:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 hcoWKFrh1BAu for <homenet@ietfa.amsl.com>; Sat, 14 Jun 2014 08:49:32 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D92D21B2C2D for <homenet@ietf.org>; Sat, 14 Jun 2014 08:49:31 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5EFnTmn026394; Sat, 14 Jun 2014 17:49:29 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7C33E293E5D; Sat, 14 Jun 2014 17:49:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qYG1UvIECwUE; Sat, 14 Jun 2014 17:49:28 +0200 (CEST)
Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0776C293E5B; Sat, 14 Jun 2014 17:49:27 +0200 (CEST)
Date: Sat, 14 Jun 2014 17:49:58 +0200
Message-ID: <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
To: Ray Hunter <v6ops@globis.net>
In-Reply-To: <539C67AA.4030501@globis.net>
References: <BEB843C7-EB1D-486A-A9A1-B99D48775D33@nominet.org.uk> <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <CAKD1Yr2mzZOvCDwyyEZHef1rk5PAxtNZRVRys43SXnD=gVxLBA@mail.gmail.com> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <CAKD1Yr0hr8Pa_QU_9mjRjbxffQ=mdgOWYSQUyLc5ewkpuf5OmA@mail.gmail.com> <F08A2136-E88F-4785-BE01-14D386B9C2D9@fugue.com> <CAKD1Yr1nhnvG2H_9eeW-Dono3cZqYaxMZaCR1vcueOQgW4xqYQ@mail.gmail.com> <E66DDB31-C318-4025-BF8A-15F2336A2A08@fugue.com> <B289FE60-E0C7-4D3B-BE21-3C7109FAC69C@ecs.soton.ac.uk> <EMEW3|c9eee95ab0d06c016200d4557ca869f9q5CFPa03tjc|ecs.soton.ac.uk|B289FE60-E0C7-4D3B-BE21-3C7109FAC69C@ecs.soton.ac.uk> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 14 Jun 2014 17:49:29 +0200 (CEST)
X-Miltered: at korolev with ID 539C6F09.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 539C6F09.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Score: MSGID : 539C6F09.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/9HzMJ0m8Nk-ZTYrUUZrj10FNvKI
Cc: "homenet@ietf.org Group" <homenet@ietf.org>
Subject: Re: [homenet] Updates to Homenet Architecture Principles doc
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jun 2014 15:49:32 -0000

> So even though link-local multicast may be part of the IPv6 base spec,
> it may be desirable to avoid use of multicast traffic where
> possible. e.g. a routing protocol could perform initial neighbor
> discovery using multicast, but then switch to unicast when maintaining
> individual neighbor associations on the longer term, or for exchanging
> information with specific neighbors.

Ah, I see.  Yes, that makes sense.

>> Then I think I don't understand what is meant by "multi-path support".  Is
>> that merely the ability to switch to a better route if one becomes
>> available?  Or is there something more to it?  Could you please clarify?

> "The inclusion of physical layer characteristics including bandwidth,
> loss, and latency in path computation should be considered for
> optimising communication in the homenet."

> I interpret the above text as requesting an ability to perform load
> balancing over equal cost paths, potentially taking into account packet
> loss and link quality when selecting which stream to send over which link.

I don't.  I interpret that as meaning that the routing protocol should be
able to pick a path using more refined criteria than just hop count.
E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops
to a single wireless one.  Doing that is not too difficult, and yields
dramatic performance improvements in some fairly simple, realistic
topologies.

Load sharing is a completely different headache.  Done carelessly, load
sharing causes issues with increased latency and jitter, and causes
intermittent connectivity problems that are very difficult to troubleshoot
if one of the links is unreliable.  It also has ghastly performance if you
balance across wireless links without taking radio interference into account.

While it's certainly an area worth experimenting with, I'd be cautious
about requiring load sharing in Homenet unless somebody knows how to do it
right in the general unadministered case.

-- Juliusz