Re: [homenet] Why configuration and routing are separate

[Henning Rogge]

On Sat, Jul 23, 2016 at 8:30 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> On Sat, 23 Jul 2016, Juliusz Chroboczek wrote:
>
>> Please let me know if you're still unconvinced.  I love arguing.
>
> Well, in my testing I got the feeling (hard to tell since it was really hard
> to get a comprehensive picture of what was going on over time), that
> sometimes HNCP lost its connection to other HNCP nodes on the lan, while
> babel was still working, and the other way around, babel went down and HNCP
> was up.

I wonder if HNCP could have a local "port" where a routing protocol
could deliver the information that a certain linklocal neighbor
address is still reachable.

HNCP would still do its own neighbor detection, but it could take
advantage of the (regularly happening) checks of the links of the
routing.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [manet] Manet address assignment

[Henning Rogge]

Hi,

on the other side a well designed routing protocol does not need much
(or any) node-specific configuration... and any mesh-wide
configuration could easily deployed by the gateway inside a DNCP/HNCP
TLV.

Henning Rogge

On Sat, Jul 23, 2016 at 1:17 AM, Juliusz Chroboczek
<j...@pps.univ-paris-diderot.fr> wrote:
> This message is being sent to the manet mailing list, with homenet in CC.
>
> I took to the microphone during this week's manet meeting to remind people
> that Homenet has designed HNCP (RFC 7788), a protocol for autonomous
> configuration of multilink home networks, and that it would be a terrible
> missed opportunity if a protocol for manet autoconfiguration were standardised
> that did not interoperate with HNCP.
>
> We at Babel Towers are currently experimenting with HNCP in a small mesh
> network.  The results are encouraging: up to some minor bugs in the
> current implementation, HNCP is able to configure a (non-mobile) mesh
> network with no operator intervention.  We are planning to spend some time
> working on shncpd, our implementation of HNCP, until it is able to work
> well in our mesh network:
>
>   - change the link sensing mechanism to work better on persistently lossy
> links;
>   - add the ability to configure just a single /128 on loopback (shncpd is
> already able to configure a /128 on each interface, which is useful
> for mesh networks but out-of-spec -- HNCP requires a /64).
>
> If this works out, the plan is then to implement an HNCP protocol
> extension that allows it to scale better in large and mobile mesh
> networks; this will necessarily involve some tradeoffs, such as being
> restricted to allocating /128.  I'll let you know more when I have code to
> show.
>
> Note that HNCP only does address configuration and naming; it does not
> negotiate routing protocol parameters nor provide monitoring facilities.
> Thus, it is not a complete solution for a MANET management protocol, and
> I believe it does not conflict with the management work being done within
> MANET.
>
> Regards,
>
> -- Juliusz
>
> ___
> manet mailing list
> ma...@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] HNCP: interaction with routing protocol?

[Henning Rogge]

On Wed, Dec 16, 2015 at 6:31 PM, Juliusz Chroboczek
<j...@pps.univ-paris-diderot.fr> wrote:
>> hnetd does address configuration on interfaces, the routing protocol picks
>> this up because that's how it's configured...? Hnetd doesn't communicate
>> directly with the routing protocol at all, right? It just sets up the
>> landscape so the routing protocol can come and survey it and communicate
>> the contents.
>
> That's exactly right (and very well put).  That's what I tried to express
> in my talk at Prague -- it turns out that HNCP is a very clean design.
> (Except where it isn't, of course.)
>
> Hnetd and shncpd do that somewhat differently.  Hnetd assume that the
> routing protocol redistributes everything.  Shncpd has closer binding to
> the routing protocol, it marks its routes as "proto 43" and expects the
> routing protocol to redistribute just that; shncpd also occasionally
> inserts dummy "proto 43" routes into the kernel, just so that they get
> redistributed into the routing protocol.  The result is that shncpd
> produces somewhat cleaner (more aggregated) routing tables, at the cost of
> requiring special configuration of the routing protocol.

Just redistributing protocol 43 will also make you miss the default
route you get by DHCP from an uplink.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Henning Rogge]

On Thu, Nov 26, 2015 at 5:49 PM, Juliusz Chroboczek
 wrote:
>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>> could easily make all that quite usable within the home.
>
> Have you ever walked a non-specialist through the process?

I wonder why this could not be fully automatic?

Setup a "press button for first login" system similar to WPS for Wifi
that deploys the certificate.

No need for the user to do something complicated.

Henning

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Henning Rogge]

On Wed, Nov 18, 2015 at 4:46 PM, Ted Lemon <mel...@fugue.com> wrote:
> Wednesday, Nov 18, 2015 9:20 AM Steven Barth wrote:
>> The basic idea behind the SHOULD is that there may be cases where either
>> physical security of links (e.g. cables) can be ensured or link-layer
>> security such as WPA for WiFi is present. In these cases (e.g. some sort
>> homenet wifi repeater) the DTLS would be redundant.
>
> WPA2, at least in PSK mode, does not provide confidentiality from attackers 
> who have the PSK.   WPA isn't even as good as WPA2.   I think relying on this 
> level of security makes sense if we have no alternative, but in no other case.

I don't think DTLS with PSK is much better than WPA2 with PSK...

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] ISIS wifi testing

[Henning Rogge]

On Fri, Oct 23, 2015 at 6:05 PM, Dave Taht <dave.t...@gmail.com> wrote:
> Except! that there is a bug in sensing the actual channel in babel on
> some radios, when last I looked. (the linux api for detecting it
> changed)

The nl80211 API changed?

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] How many people have installed the homenet code?

[Henning Rogge]

On 10/22/2015 11:25 AM, Juliusz Chroboczek wrote:

SHNCPD is good for a few first tests, but it only contains a subset of
the useful HomeNet features.


Huh?  What useful features are missing?


What is about the interaction of SHNCPD with (M)DNS? Can I add the 
hybrid-proxy and expect it to work?



(Yes, I've got your patches, just too busy right now.)


Good to hear.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] How many people have installed the homenet code?

[Henning Rogge]

On Wed, Oct 21, 2015 at 5:10 PM, Dave Taht <dave.t...@gmail.com> wrote:
> is it up from 8?
>
> Dave Täht

I did experiments in the CORE network emulator with shncpd... not sure
if this counts.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Dynamic metrics in IS-IS [was: Info about IS-IS demo from Bits N Bites Prague]

[Henning Rogge]

On Wed, Sep 30, 2015 at 12:20 PM, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> On Wed, 30 Sep 2015, Juliusz Chroboczek wrote:
>
>> Please check the Babel web page, which links to a number of papers and
>> draft papers that contain both experimental and simulation data.
>
>
> Are you referring to
> http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find 4 papers,
> two have broken links, one is for ad hoc networks, and another one is
> multi-hop mesh protocols.
>
> It's not obvious to me that homenet is an ad-hoc mesh network, at least
> according to the wikipedia page. I don't expect all nodes that participate
> to relay messages.

I would say that everything that works on an ad-hoc mesh network will
also work as good on a wired network... maybe a bit better because of
the "missing frame loss".

>> Please check the results of previous Battlemeshes.
>
> I found http://battlemesh.org/BattleMeshV7/Tests but I can't find any
> results, only test cases, and all of the test cases are mesh networking
> cases.

These are the tests and results from the battlemesh v8:
http://docs.battlemesh.org/v8/

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Dynamic metrics in IS-IS [was: Info about IS-IS demo from Bits N Bites Prague]

[Henning Rogge]

On Fri, Sep 18, 2015 at 7:18 PM, Juliusz Chroboczek
<j...@pps.univ-paris-diderot.fr> wrote:
>> - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo
>
> This is interesting.  Could you please share your experimental data?
>
> Getting dynamic metrics right in link-state is tricky, and using them in
> a reliably flooded link-state routing protocol has never been done before
> to my knowledge.  I have no doubt that you and David are highly competent
> engineers, but since this is something that has never been done before,
> I think it is essential that you share your experimental data.
>
> I refer you to [1] that compares an early version of babeld with an early
> version of OLSR-ETX.  Henning is a highly competent engineer, at it took
> him years of hard work to get ETX right in OLSR.

I would also be interested in this...

a few years ago I wrote a variant of OLSR (v1) with a semi-reliable
transport (some linklocal retransmission scheme) but stopped working
on the thing because ETX routing metric I had contained too much
change/noise anyways.

Reliability is not that useful if the metric has changed in a relevant
way between two iterations of the update.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Henning Rogge]

On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg
<markus.stenb...@iki.fi> wrote:
> On 31.8.2015, at 13.16, Henning Rogge <hro...@gmail.com> wrote:
>> Typical configuration of a cheap router would be to run dnsmasq for
>> local DHCP and as a DNS cache. If each of these DNS caches could
>> forward DNS queries for *..homenet to the relevant
>> homenet router, it would not be necessary to pool all the information
>> in an elected DNS “master".
>
> For naming this works as is fine in our current implementation too; all you 
> get is some duplicates (foo.link1.rid1.home and foo.link2.rid2.home may both 
> exist, even if link1.rid1 is same link as link2.rid2).

You mean that a Homenet user use a switch to connect two Homenet
routers AND a Host ?

Or maybe a Host with two interfaces connected to two Homenet routers?

Henning

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Henning Rogge]

On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg
<markus.stenb...@iki.fi> wrote:
> Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host 
> (foo).
>
> Given no election, use of e.g. mDNS to determine hosts/services would result 
> in the host showing under both rid1.home and rid2.home. That isn’t a problem 
> in naming case (you have IP => name, and name => IP resolving), but for 
> service discovery it kind of sucks.

Okay, I see the problem with the hierarchical namespace when two when
we have this "host switched to multiple HNCP routers" situation.

It would be great if we would get one common (m)DNS name for the host,
even if it got multiple IP addresses.

Would it be a solution to use a DNS "second level" name for each
ethernet segment with hosts attached but NOT include the routers into
the DNS name? If you connect two homenet routers to the same ethernet
segment, they should know because they see each others HNCP packets
(unless its a LEAF interface... which contradicts the switched
situation a little bit). Both sides could agree on a common "Link
segment" name and announce the host with "host1.link-segment.home".

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Henning Rogge]

On Fri, Aug 28, 2015 at 9:49 AM, Markus Stenberg markus.stenb...@iki.fi wrote:
 On 28.8.2015, at 10.02, Henning Rogge hro...@gmail.com wrote:
 So what IS the proposed solution for a decentralized HNCP configured
 homenet to share local configured DNS names with the rest of the
 homenet?

 For sharing in general, there are two methods (as far as HNCP goes);

 - publish a DNS Delegated Zone TLV that points to a (local or remote) DNS 
 server that responds for that zone.

central server sounds bad for distributed network.

 - publish Node Name TLVs for individual nodes (won’t scale forever, but 
 possibly enough).

That could work... still, if every DNCP node publishes a DNS name for
the node (and maybe another one for a few locally attached non-DNCP
hosts) this would increase the size of the DNCP database a little bit.
Wasn't there a size limit for the database (or was it per node?)?

 If the node that has configured state _is not_ running HNCP, then options 
 boil down to:

 - DHCPv6, mDNS assuming first-hop router cares and does DHCPv6/mDNS (shncpd, 
 cough)
 - DNS-update aimed at the right place (+ injection of DNS Delegated Zone TLV 
 per zone somewhere in the HNCP cloud)

Yes, this would be more complex.

But pushing the local router as a nameservice would be enough to
inject the knowledge of the HNCP cloud to the attached hosts.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Henning Rogge]

On Wed, Aug 26, 2015 at 11:50 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 On Wed, 26 Aug 2015, Henning Rogge wrote:

 I wonder if HNCP routers should apply all addresses/prefixes to its local
 interfaces, but should check for an existing route to the HNCP router that
 announce the prefix before providing it via DHCP or RA to hosts.


 Let me rephrase what I think you're saying and tell me if I'm correct:

 Your worry is that HNCP will determine neighbors and speak HNCP well enough,
 but the routing protocol thinks the link is so bad, that it's effectively
 has partitioned the network (because this was the only link connecting the
 two (now) parts), and since there might be two uplinks, you want HNCP to
 detect this partition, and only hand out ISP1 prefixes on the side where
 ISP1 works, and only ISP2 prefixes, on the ISP2 side that works. Also, if
 the network is partitioned, you want prefixes no longer reachable to be sent
 corresponding RAs with zero lifetime etc, to make hosts no longer use them
 for new connections?

This is a good example.

 So one way of doing this would be for hnetd to check if the ISPx prefix (for
 instance /56) is in the routing table, and if it isn't, it should not use it
 to put addresses on interface etc, and if it goes away (at least for any
 duration of time), stop using it.

Yes. If DHCP server and radvd wait until the route to the prefix is
available in the routing table, we keep the decision about
reachability to the routing protocol without having a hard
dependency on it.

 I don't remember seeing this discussed anywhere, but it might very well be
 something that should be done. I would imagine HNCP is reacting on ISP1 WAN
 link going down and stopping to use the ISP1 prefix, but if there is a break
 within the homenet (routing protocol wise), nothing is done as long as HNCP
 is up.

 One way of solving this would be to create fate-sharing between HNCP and the
 routing protocol. Ie, HNCP wouldn't do anything unless there is a valid
 routing protocol adjacency with that neighbor (=fate sharing).

Yes.

HNCP has its own control plane (and it needs this control plane),
but if we use the neighbor information within HNCP to decide if a
prefix is reachable we might create a different view than the routing
protocol, which has its own idea what is reachable and what not.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Henning Rogge]

My problem is not with the prefixes assigned to the interfaces of HNCP
routers itself, my problem is with the prefixes provided to attached
hosts.

If I understand HNCP right then the uplink will announce a prefix
which should be used by all routers for the attached hosts.

The problem will appear if HNCP learns about this prefix through DNCP
but the routing protocol cannot provide a route to the uplink (because
hysteresis decided one of the links is too bad).

I wonder if HNCP routers should apply all addresses/prefixes to its
local interfaces, but should check for an existing route to the HNCP
router that announce the prefix before providing it via DHCP or RA to
hosts.

This would not create a dependency loop between routing protocol and
HNCP because the routing protocol does only advertise the
addresses/prefixes configured on the HNCP interfaces. But it would
prevent HNCP to announce a prefix that is not reachable via the
routing protocol.

Henning Rogge

On Wed, Aug 26, 2015 at 11:33 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
 It is not uncommon for wireless links to use some kind of hysteresis
 on a routing protocol. The problem/feature of D/HNCP is that it is
 independent of the routing protocol... so it does not know.

 I'm not sure I'm following you.

 All that shncpd does is to announce attached prefixes over the routing
 protocol.  It is then the routing protocol's business to pick a path to
 one of the routers advertising the prefix (or to drop all such routes, if
 the link quality has collapsed too much).

 -- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Henning Rogge]

On Wed, Aug 26, 2015 at 12:06 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
 Yes. If DHCP server and radvd wait until the route to the prefix is
 available in the routing table, we keep the decision about
 reachability to the routing protocol without having a hard dependency
 on it.

 So if a route is flapping, hosts get or don't get an IP depending on the
 exact time when they send a DHCPREQUEST or NS?  Is that better than always
 assigning an IP to hosts, and expecting ICMP to signal route flapping in
 real time?

Are you talking about a route that is created and vanishes every few
seconds or minutes?

I would guess some kind of hysteresis would be okay. Activate a prefix
if you had a route for X seconds... deactivate it if you loose it for
X seconds.

Still, assigning a source IP address without a route to it is a bad
thing, some client applications might just keep trying instead of
moving to a different source address.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Reachability of distributed prefixes

[Henning Rogge]

Hi,

I am experimenting with SHNCPD at the moment and wonder about a detail
in the Homenet prefix distribution to attached hosts.

Does HNCP somehow make sure that there is a route towards the prefix
it distributes? While D/HNCP checks that there is a path of links, the
routing protocol might decide that one of the links is too
unstable/slow for traffic and does not use it for routing.

What is the preferred way to deal with this situation?

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Henning Rogge]

On Wed, Aug 26, 2015 at 2:31 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
 So if a route is flapping, hosts get or don't get an IP depending on the
 exact time when they send a DHCPREQUEST or NS?  Is that better than always
 assigning an IP to hosts, and expecting ICMP to signal route flapping in
 real time?

 Are you talking about a route that is created and vanishes every few
 seconds or minutes?

 What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal
 with prefixes that last less than a few hours.  See for example RFC 4862
 Section 5.5.3 paragraph e2.  (That's just an example, there are other
 reasons why yo-yo RAs are a bad idea.)

 Short-term reachability indications are sent to hosts in a reactive manner,
 using ICMP unreachables.  If any applications are unable to do the right
 thing with ICMP unreachables, we should fix the applications.

I am not aware of any application doing anything more than try to
open the connection again.

How do you propose the application to react? Most applications leave
the source-IP selection to the operation system...

does any OS currently change the preference order of IPv6 source
prefixes when it gets ICMP unreachable messages?

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Henning Rogge]

On Wed, Aug 26, 2015 at 3:27 PM, Philip Homburg
pch-homenet...@u-1.phicoh.com wrote:
I am not aware of any application doing anything more than try to
open the connection again.

How do you propose the application to react? Most applications leave
the source-IP selection to the operation system...

does any OS currently change the preference order of IPv6 source
prefixes when it gets ICMP unreachable messages?

 I never bothered to automate, but I regularly switch prefixes by changing
 the preference times in RAs. That works very well.

 Linking general ICMP unreachable messages to a source prefix sounds very hard
 to me.

RA's are generated by the HNCP router, so the generation could take
the routing table into account (put prefixes WITH routes in preferred
places).

If the routing protocol would export the distance to the destination
in form of the routing table metric value, the RA generation could
even make sure that the closest gateway is always the preferred one.

So we can manipulate the published RAs in a way that the hosts will
take normally one the HNCP router prefers?

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Henning Rogge]

On Tue, Aug 25, 2015 at 7:38 PM, Alia Atlas akat...@gmail.com wrote:
 There is also the point that multipath choices tend not to be
 isometric... just because the two paths from your local point of view
 seem to be good they are not necessarily good from the point of view
 of the next hop.


 In a way that can't be captured by link metrics?  I haven't really looked at
 the unique characteristics for wireless.  I'm happy to do a bit of
 self-education.

Imagine a network with three wireless routers (A,B,C)... A is the
uplink, you are C, but both A and C can only see B.

All routers are dualband routers (all have both a 2.4 GHz and a 5 GHz radio).

From your (C) point of view the multipath-solution is easy, one path
use 2.4 GHz (C to B to A), the other one uses 5 GHz (C to B to A).

But when your IP packet arrives at B, B doesn't know it is part of a
multipath stream... so forcing both streams to stay on their frequency
is not trivial if you don't want to do source routing.

There is a solution for this easy example (as Juliusz will certainly
be able to tell you), but there are more complicated setups which are
even more difficult.

Multipath on wireless links is easy to mess up, so I would suggest NOT
including it into the feature-set required by Homenet.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Henning Rogge]

On Tue, Aug 25, 2015 at 7:02 PM, Alia Atlas akat...@gmail.com wrote:
 Ted, I asked a question about a feature that is considered critical in every
 routing environment that I am familiar with.
 I find it frustrating that looking ahead to significantly more complex home
 networking topologies and link types, which may be
 many years out still, is unexceptional, but asking about a feature that
 allows better use is described as premature optimization.
 I am asking about a routing requirement.

 I still am not clear on how link interference is handled for different
 destinations.

The options I know are ignore it or include the interference domain
size into the link cost.

Still, using multipath in wireless environments can be tricky... it is
quite easy to mess up even with two paths and get less throughput than
from a single path.

There is also the point that multipath choices tend not to be
isometric... just because the two paths from your local point of view
seem to be good they are not necessarily good from the point of view
of the next hop.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NTP in Homenet?

[Henning Rogge]

Hi,

would be nice to have a NTP daemon on every Homenet router... gateways pull
their time from the uplink, every other router pulls time from the gateway
routers.

Henning Rogge

On Tue, Aug 18, 2015 at 2:34 PM, Juliusz Chroboczek 
j...@pps.univ-paris-diderot.fr wrote:

 How do Homenet routers configure NTP?  Just use the pool?

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

[Henning Rogge]

On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch to...@isi.edu wrote:
 DAD is also needed to detect duplicates due to host misconfiguration,
 such as when a cloned MAC is added to the same network or when addresses
 are duplicated by other means (e.g., DHCPv6 misconfiguration).

 I couldn't confirm, but isn't this also not a local decision? I.e., if
 DAD fails you might end up with a duplicate address even when you set
 your IP addresses based on the burned-in MAC because others could select
 the same address randomly (I didn't see how that was avoided by the
 self-assignment algorithm).

If you have a duplicate MAC then DAD will not safe you... you cannot
communicate anyways because of a layer-2 problem.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

[Henning Rogge]

On Wed, Aug 12, 2015 at 8:23 PM, Joe Touch to...@isi.edu wrote:
 That's true, but specific protocol behaviors do address this issue
 already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs.

 DAD is a negative information protocol, i.e., a lossy link can give a
 false positive. This issue is already addressed Sec 4.4 of RFC 4429: the
 effect of L2 losses can be mitigated by recommending a different value
 for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this
 parameter might need to be defaulted to a different value for particular
 link types, and such might need to be the case for 802.11.

Luckily DAD is mostly needed for randomized IPv6 addresses... if you
use the MAC address for generating the IP you are either fine or you
have a MAC level collision, which means you have an unsolvable
problem.

(it gets even worse on 802.11 IBSS/Adhoc mode)

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

[Henning Rogge]

On Wed, Aug 12, 2015 at 7:17 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 I'd say most applications people actually use start behaving very badly
 around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really get
 affected etc. I'd imagine most people I interact with that design protocols
 design protocols have in their mind that the packet loss rate is around this
 level, not higher.

 So for me, the contract that 802.11 needs to fulfil for the IETF not to
 start looking into changing IP for 802.11, is for 802.11 networks to deliver
 broadcast and multicast packets with around 0.1% packet loss (or less) as a
 design goal for normal operations.

The problem is we are dealing with more and more wireless devices, so
the medium starts to become congested more easily.

0.1% - 1% packet loss (not frame loss) is possible for unicast, but
0.1% multicast packet loss is unrealistic.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Henning Rogge]

On Wed, Aug 12, 2015 at 5:20 AM, Alia Atlas akat...@gmail.com wrote:
 Yes - downstream paths, as I already said.  That is going to next-hops that
 are closer to the destination than the computing router.  As long as your
 next-hop's distance to the destination is strictly decreasing, it is safe to
 use.

In theory yes... in practice (especially in the presence of wireless
links) you might just spam your airspace by producing lots of
additional collisions.

 There are two questions.  First, is the desirable to load-balance among
 different paths useful/necessary/unnecessary in homenet?  Second, is that
 accomplished with metric assignment that encourages equal-cost, are
 downstream paths used, and/or is there a way of doing explicit paths?

Making the metric too simplistic means you cannot deal with a
heterogeneous network like a mixture of ethernet (of different link
speeds) and wifi (with LOTS of different link speeds and frame loss).

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Despair

[Henning Rogge]

On Mon, Aug 10, 2015 at 10:34 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 Donald Eastlake posted this a few days ago:

 - 802.11 does have a feature called GCR -- Groupcast With Retries,
 which was part of the 802.11aa amendment, although it is not widely
 implemented. It includes such features as a way for the AP to send
 several multi-destination frames and then, using unicast, to poll
 associated stations for a bit map of which of those frames they
 correctly received (BlockAck) and a feature for the AP to
 spontaneously transmit a multi-destination frame more than once
 without causing confusion for improved reliability.

Okay...

this is quite new and I am not sure it will solve all the multicast
problems for 802.11. Neighbor discovery (both IPv6 and routing
protocol) has potentially to deal with a lot of neighbors, some of
them not even known to the transmitter. It also feels like a lot of
consumed airtime to replace a multicast with a multicast and one
unicast for each known neighbor. This could be dozens of media
accesses.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Despair

[Henning Rogge]

On Mon, Aug 10, 2015 at 9:32 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 IETF standards generally assume that multicast and unicast are delivered
 with a similar level of packetloss (which is low).

 Not all 802.11 implementations have the multicast ACK mechanism implemented,
 thus it would seem that multicast will be less likely to get delivered to
 the recipient over these 802.11 implementations.

 For me, it seems these 802.11 broadcast/multicast ACK functions should be
 mandatory to implement if the device wants to support IPv4 and IPv6
 networks.

Excuse me, multicast ACKs on 802.11?

I know that some implementations/stacks split up multicast into
several unicasts (which will then be acked and will have
retransmissions), but I have yet to hear about multicast ACKs in the
IEEE 802.11 standard.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Despair

[Henning Rogge]

On Mon, Aug 10, 2015 at 11:33 AM, Lorenzo Colitti lore...@google.com wrote:
 Sure, but for small packets, it's pretty unlikely that unicast would be
 cheaper. An RA will likely only be 100 or 200 bytes.

First 802.11 has aggregation, so it is possible to combine the unicast
media access with other outgoing unicasts.

There is also multi-user MIMO coming, which means a AP can talk to
several other stations simultaneously.

Both factors can make multiple short unicast frames more efficient
than a single multicast, but only the linklayer has enough information
to decide this.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] MIF support [was Moving forward.]

[Henning Rogge]

On Tue, Jul 28, 2015 at 2:41 PM, Margaret Cullen mrculle...@gmail.com wrote:

 On Jul 28, 2015, at 2:58 AM, Brian E Carpenter brian.e.carpen...@gmail.com 
 wrote:
 The former is obvious but I'm not sure that any case has been made to require
 MPVDs in the basic Homenet model. There are no references to the MIF WG or 
 its
 documents in the Homenet architecture RFC.

 Since MPVDs are implemented on hosts, and informed by information distributed 
 in RAs and/or via DHCP, Homenet should already support MPVDs to some extent.  
 There are some issues with how Homenet would distribute the MPVD DHCP 
 options, most of which would apply to other container options, and we have a 
 group of people looking into that now.  Assuming we can resolve those issues 
 to everyone's satisfaction, Homenet will support MPVDs with no additional 
 complexity in the Homenet protocols.

I think the reason why this MIF support thread started was that
different gateways might be good or bad (because of the topology/links
in between) for one router or the other one. The question is how to
push this local information to the attached Hosts.

Transporting DHCP options over HNCP has nothing to do with it, because
it will be a local decision anyways, not one decided by the gateway.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] HNCP, RA and DHCPv4

[Henning Rogge]

On Mon, Jul 27, 2015 at 3:58 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
 During my quick talk on Wednesday, I mentioned that I had been pleasantly
 surprised at the very clean interaction between the protocols:

   - HNCP redistributes assigned prefixes into the routing protocol;
   - HNCP redistributes assigned prefixes into the RA and DHCPv4 servers;
   - the routing protocol redistributes the default route into RA and DHCPv4.

 That's very elegant -- unless I've missed something, there are no other
 cross-protocol interactions in the subset of the Homenet stack that is
 implemented in shncpd.

There is one thing I worry about with this strategy...

if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers,
who makes sure that these are prefixes that are reasonable good
measured by the metric of the routing protocol?

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Mesh networks in the homenet

[Henning Rogge]

On Wed, Mar 25, 2015 at 5:15 PM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Err, no.  It's an A-B-C situation where each (even B) has 1 interface,
 and all are in an IBSS.  This is the situation described in that draft.

 Are there 1-interface routers in homenet?


 In an 802.11 IBSS, I would assume yes.


 Well IBSS is not made to have 1-interface routers on them, so this
 (1-interface routers) is not really good to do, in my personal oppinion.

 IBSS is made to have 1-interface Hosts on it, not routers.

one of the typical use-cases of IBSS mode was to connect larger amount
of routers for a mesh network.

 Remark this is my IMHO and a number of other people disagree with this.

 I know.

 I just tell that you can build a very good ad-hoc network without an AP
 and with 2-interface routers.  At that point there is no hidden-terminal
 problem.

Unfortunately this is wrong.

The number of interfaces is totally irrelevant to the hidden station
problem. The only question is if you have one wireless radio interface
(among many on a router) connecting to two other routers (with maybe
many more interfaces) that cannot hear each other on this interface.

It can even happen on AP/client networks if you use them to connect
multiple routers. There is no guarantee that the clients can see each
other.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] rt protocol comparison on criterion 'transitivity' A-B-C draft-baccelli-intarea-adhoc-wireless-com-00.txt

[Henning Rogge]

On Tue, Mar 24, 2015 at 11:06 PM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
 Hello,

 During the slide presentation by Margaret we saw a criterion for protocol
 comparison describing 'transitivity', in the sense A sees B sees C but A
 does not sees C - aka a 'hidden terminal problem' in WiFi IBSS mode.

You can also have this with AP mode or Wifi-Direct... two routers with
a Wifi client interface connected to the same router but not seeing
each other.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] L2 link status [was: More about marginal links]

[Henning Rogge]

On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote:
 The basis for the metric in RFC 7181 is out of scope.  So what did you
 use?

This:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04

I am still using the multicast loss (plus the raw link speed) to judge
the links, but I have done some early experiments with integrating the
L2 frame statistics too. Not sure it works that well for wifi without
a lot of probing, much more than you need for getting an useful link
speed).

 Also I'm not sure what you meant by the MPR code.  Did you leave in
 the LINK_METRIC TLV and leave out the rest of RFC 7181?

Multipoint Relays. Its a method to reduce the flooding overhead in a
wireless mesh network. Its defined in RFC 7181, but its a modification
of NHDP so I put it into my NHDP implementation.

 So my point still stands that there is nothing like LQM is anything
 over WiFi (more correctly 802.11).

With an Atheros card I get both transmitted frames, retransmitted
frames and (completely) lost frames on the sender side of a link...
its just that these values are not that useful when most of your
wireless links are not transporting traffic.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] L2 link status [was: More about marginal links]

[Henning Rogge]

Sorry,

too much working on the implementation side of NHDP/OLSRv2 in the last
years... should have thought a bit more about the reply before sending
it.

Yes, you are correct that RFC6130 does not contain the description of
the link metric...  it only contains a rough EWMA based link quality
hysteresis that switches on and of links. I don't even think the
algorithm defined in the RFC is really useful (but its easy to plug in
a different one because the Link Quality calculation and decision is
just local).

I was thinking about the Link Metric NHDP extension defined in RFC7181
(which can easily be used without using the OLSRv2 routing), which is
based on Incoming/Outgoing Link Metric values.

(in my implementation I put the whole Link Metric and MPR code into
NHDP to make them usable without OLSRv2)

Henning Rogge


On Tue, Mar 3, 2015 at 12:28 AM, Curtis Villamizar
cur...@ipv6.occnc.com wrote:
 Henning,

 You cut the following off the top of your reply.

  The Neighborhood Discovery Protocol (RFC 6130) has a similar
  mechanism... each node collects local link quality information and
  then shares them from time to time with all neighbors, which means
  everyone knows about both directions of a link.
 
  Henning Rogge


 RFC 6130 uses probes (hello message success rate).

 Cutting this off makes a big difference.  See below.

 In message 
 CAGnRvup-F4_A1-sHkh3EWRgrX=iuthbdmjzz+xk_g+7bm+e...@mail.gmail.com
 Henning Rogge writes:

 On Sun, Mar 1, 2015 at 11:14 PM, Curtis Villamizar
 cur...@ipv6.occnc.com wrote:
  RFC 6130 uses probes (hello message success rate).

 No, it does not... at least not for calculating the link metric.

 The discussion was the quality measurement.  The quality measurement
 uses hello message success rate.  See section 14 in RFC 6130.

 The discussion was not link metrics.  You chopped the prior discussion
 when quoting the one sentence above.  Below I describe the why RFC
 6130 Link Quality is nothing like LQM.

  For example: If an AP sends 100 packets a second to a neightbor and 5
  drop it would be better to send one LQM packet and know that loss is
  5% rather than have to send 100 hello packets in addition to the 100
  data packets to reliably know that loss is 5%.  (In MPLS it could be a
  billion packets between LM packets).
 
  LQM does not rely on a count of probe packet success.  Please reread
  what I sent earlier or read about PPP LQM or MPLS-TP LM OAM.
 
  Please compare RFC 6130 section 14.2 (Basic Principles of Link
  Quality)

 Link quality and Link metric are two different kind of things for
 NHDP/OLSRv2.

 Link quality is used for a hysteresis mechanism that can make a link
 symmetric/asymmetric.

 Link metric (as defined in RFC 7181) is used for path selection.

  with RFC 1989 and RFC 6375.  In RFC 6375 look at Section 2.2
  (Packet Loss Measurement) and Section 3.1 (Loss Measurement Message
  Format).  RFC 6130 has no comparable mechanism.

 RFC6130 (NHDP) and RFC 7181 (OLSRv2) define the incoming link METRIC
 calculation as an external process. It can be anything, as long as it
 gives you a dimensional link cost in the right range.

 I admit the splitup between RFC6130 and RFC7181 is a bit confusing...

 Henning Rogge

 I know the difference between link quality and link metric.

 You just jumped from ND to OLSRv2 for MANET.  RFC 7181 does not
 preclude using a LQM-like mechanism, but neither RFC 6130 or RFC 7181
 define such a mechanism.

 The discussion was regarding doing something like LQM and three
 messages ago you stated that RFC 6130 already had something like LQM.
 Neither RFC 6130 or RFC 7181 define a mechanism anything like LQM.

 Curtis

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] L2 link status [was: More about marginal links]

[Henning Rogge]

On Sun, Mar 1, 2015 at 12:52 AM, Curtis Villamizar
cur...@ipv6.occnc.com wrote:
 If any of the control packets drop, drop a partial result, repeat
 later, and compare to the last complete result.

 Is one cycle per neighbor too much?  How about one cycle per neighbor
 each 5 seconds?  If B is the AP it sends only one packet per cycle
 but both sides get accurate drop rate for both directions.

I went even further and restricted the probing to a fixed amount per
interface... to prevent the wifi network from overloading in crowded
adhoc networks (where everyone can see everyone).

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] L2 link status [was: More about marginal links]

[Henning Rogge]

On Fri, Feb 27, 2015 at 10:37 PM, Curtis Villamizar
cur...@ipv6.occnc.com wrote:
 Henning,

 How can a router make use of throughput to a mostly idle neighbor?
 How do you get packets sent to a neighbor that dropped or packets that
 a neighbor sent to you that didn't arrive here?  Raw link speed or
 packet and byte counts don't by themselves tell you much.  The
 equivalent of PPP LQM or MPLS-TP LM OAM would be the sort of thing
 needed is you didn't want to use BFD with a high probe rate.

You need a bit of probing traffic... a few packets per second are
enough to give you an idea about the speed of the link. Of course you
only need to probe neighbors that you did not send normal unicast
anyways since the last probe.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] More about marginal links [was: Routing protocol comparison document]

[Henning Rogge]

On Fri, Feb 20, 2015 at 8:56 AM, Teco Boot t...@inf-net.nl wrote:
 Bad luck, I kindly ask you to pay a little more attention to it. Link metrics 
 for wireless links are crucial, but let's not forget wired links.

 Some years ago, Thales NLD worked on olsr-lc (link costs, ETT). A plugin 
 probed WiFi link speed with large  small packets, filtered out jitter and 
 used the outcome as link metric (merged with ETX, I think). For static 
 networks and very patient people, it may work. For mobile networks, it is 
 far, far to slow. Convergence is tens of minutes. Speed up some timers 
 increases load on the wireless links to unacceptable levels. So it died.

 But for wired links at homes, this plugplay mechanism could work out well. 
 No L2 API needed.

There is also the linklayer database approach I selected for my
olsrd2 implementation. Instead of hardcoding linklayer specific code
into the metric, I split the codebase into link layer gathering code
(which is often OS and linklayer specific), generic routing metric
code... and a generic API in between that stores the values.

This makes it quite easy to adapt the codebase to new linklayer types.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] More about marginal links [was: Routing protocol comparison document]

[Henning Rogge]

On Fri, Feb 20, 2015 at 9:19 AM, Teco Boot t...@inf-net.nl wrote:
 There is also the linklayer database approach I selected for my
 olsrd2 implementation. Instead of hardcoding linklayer specific code
 into the metric, I split the codebase into link layer gathering code
 (which is often OS and linklayer specific), generic routing metric
 code... and a generic API in between that stores the values.

 This makes it quite easy to adapt the codebase to new linklayer types.


 So you have the placeholder for an automatic ethernet link speed detection. 
 Great!

 We cannot trust ethernet port L2 feedback. Ports can be connected to switches 
 with multi-rate ports. Could be powerline, wired_over_wireless bridges or 
 other stuff that hides a slow link. In homes, there is no place for protocols 
 that cannot detect and handle such cases.

At the moment I just get the ethernet port link speed... that is not
really good for switched ports, but its better than nothing.
http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master

If you have hardware with a built-in switch that can report the
link-speed, it would be easy to add code that integrates this (and
some traffic statistics).

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] More about marginal links [was: Routing protocol comparison document]

[Henning Rogge]

On Fri, Feb 20, 2015 at 9:51 AM, Teco Boot t...@inf-net.nl wrote:
 At the moment I just get the ethernet port link speed... that is not
 really good for switched ports, but its better than nothing.
 http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master

 If you have hardware with a built-in switch that can report the
 link-speed, it would be easy to add code that integrates this (and
 some traffic statistics).

 Your SW depends on ethtool, right? Not a problem, this is implementation 
 detail. Link speed probes could be added for verification the ethtool 
 provided info.

No, it does directly call into the operation system. Calling a
different executable and parsing the output is a good source for
subtle bugs.

 And yes, I didn't mean we cannot use the 80% solution. What I want to say is 
 that the Homenet Routing Protocol shall be able to use all the link metrics 
 it can get.

 I am still worried about loops caused by dynamic link metrics used by a link 
 state routing protocol. For me, this is the major difference between ISIS and 
 Babel. Thats because I don't code the protocol. If I was, I would be worried 
 about the non-IP transport in ISIS.

It is a matter of metric stability... so you need a good hysteresis
and post-processing to make it work.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Henning Rogge]

On Thu, Feb 19, 2015 at 7:18 PM, Ole Troan otr...@employees.org wrote:
 there are very few shared media around anymore. I don't think I've ever been 
 connected to a 10base5.
 why should the IP subnet model emulate a shared medium, when the physical 
 topology is a star.

 wireless with security is also a star topology, with a unidirectional 
 broadcast channel.

Unfortunately on layer-1 both are still broadcast... you send a
unicast, it might interfere with anyone else in range.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Henning Rogge]

On Fri, Dec 19, 2014 at 11:54 PM, Matthieu Boutier
bout...@pps.univ-paris-diderot.fr wrote:
 You might also need to combine the features of the gateway with the
 metric(s) of the path to the gateway.

 Its not really useful to select a faster gateway if the path towards
 the gateway goes over a slow wifi link.

 I do end-to-end measurements in my mosh implementation, so we should
 not have the problem.  The host selects a source address, in fact a
 pair (src, dst), depending on the performances of the whole path
 determined by this pair.

Does this really scale well?

If every application on every attached computer in the Homenet
measures the end-to-end performance through every gateway... that
could be a LOT of overhead for larger Homenet installations.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Henning Rogge]

On Fri, Dec 19, 2014 at 6:31 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
 Sounds interesting. In the ideal world, that would be a pluggable
 policy algorithm. Lowest RTT may not always be the best choice.

 It is, in our particular context.  That's the nice thing about working at
 the application layer -- you are the application, so you have a pretty
 good idea of what the desirable properties are.

 Are you sure?

 This particular debate aside, I think we're in agreement about the
 underlying issue -- source selection in networks with source-specific
 routing is an interesting problem, and one that we haven't explored much
 yet.

You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.

Its not really useful to select a faster gateway if the path towards
the gateway goes over a slow wifi link.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Clarification on Routing Thoughts

[Henning Rogge]

 I think Joël's reluctance about hopcount qualifying the gig-e/wifi
 choice may change if considering wifi-ac instead. I.e. hopcount may be
 good to qualify a choice between Gigabit Ethernet and Gigabit wifi.

Measuring any kind of wifi connection just with hopcount is not a
good idea. Even 802.11ac will downgrade to a few Mbit/s if the
connection is bad.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Henning Rogge]

On 08/12/2013 11:40 AM, Mikael Abrahamsson wrote:

On Mon, 12 Aug 2013, Teco Boot wrote:


Joel Jaeggli mentioned the forwarding performance. Today's homenets
are mainly single subnet with link-speed forwarding between (gig)
ethernet ports, in hardware. L3 forwarding in software with single
uplink or WiFi port at near to gig speed is doable. Forwarding in
software on all ports require a new generation of low power and cheap
CPU, I think. So probably use hardware forwarding as much as possible?


Hardware assisted forwarding might be problematic due to us deciding on
new functionality (source based routing for instance). I've read that in
some routers the forwarding is done by microcode implemented by the
hardware manufacturer, hindering the integrator (who buys the SoC in
bulk) from doing what might be needed.

So yes, forwarding performance is a concern, at least when we're talking
above 100 megabit/s.

I also think it would be beneficial if we could figure out as soon as
possible what the requirements are on the forwarding plane, writing this
down, so that hardware designers can avoid putting functionality into
hardware that won't do what we need going forward.


I agree, software forwarding should be the standard way. That makes it 
also more easy to adapt different routing protocols to HOMENET.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Henning Rogge]

On 08/09/2013 04:11 AM, Ted Lemon wrote:

On Aug 8, 2013, at 9:49 PM, Hartog, F.T.H. (Frank) den frank.denhar...@tno.nl 
wrote:

At the same time, new and much smaller devices are introduced in the home. E.g. light 
bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we 
should define a baseline definition of what we mean with small device anno 
2013 to frame the homenet arch discussions and documents. Regards, Frank.


Do bear in mind that Olafur is talking about home routers here, not lightbulbs.


From a RAM/CPU perspective no current home routers should have a 
problem with IPv6. Its just that some manufacturers don't integrate the 
necessary components into their basic firmware.


I think IPv6 support should be mandatory for Homenet routers. Maybe they 
won't have an uplink to the Internet with IPv6, maybe they have some 
attached devices without IPv6, but the software on the core Homenet 
routers should have access to IPv6.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet