Re: [homenet] Updates to Homenet Architecture Principles doc

Ray Hunter <v6ops@globis.net> Sun, 15 June 2014 10:51 UTC

Return-Path: <v6ops@globis.net>
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 7D7B11B2BEC for <homenet@ietfa.amsl.com>; Sun, 15 Jun 2014 03:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 h77UqoGY7qlW for <homenet@ietfa.amsl.com>; Sun, 15 Jun 2014 03:51:25 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 037251B2BEA for <homenet@ietf.org>; Sun, 15 Jun 2014 03:51:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B351A871517; Sun, 15 Jun 2014 12:51:23 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHc7nQbpo5oL; Sun, 15 Jun 2014 12:51:23 +0200 (CEST)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 8EA8987005A; Sun, 15 Jun 2014 12:51:23 +0200 (CEST)
Message-ID: <539D7A9F.5000407@globis.net>
Date: Sun, 15 Jun 2014 12:51:11 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
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> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr>
In-Reply-To: <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BF5d3qEgJc6744xs0KXkOTbJvSQ
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: Sun, 15 Jun 2014 10:51:26 -0000

Juliusz Chroboczek wrote:
>> 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
>
>
Your interpretation of the current architecture text also seems 
perfectly valid, and is indeed much simpler to implement.

Should the text then rather say "Path selection in Homenet needs to be 
more sophisticated than measuring pure hop count due to the use of 
heterogeneous link technologies, and therefore the routing protocol 
should be capable of utilising multiple link-dependent metrics, such as 
bandwidth, delay, and link reliability", rather than mentioning "optimised"?

IMHO That revised text would provide a very clear selection criteria for 
preferring certain routing protocols over others.

Or do you think the text is OK as is?

-- 
Regards,
RayH