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

What you mention is for media streaming, and the wifi problem is primarily burst loss. Correcting that is expensive, whether its done at l2 or higher layer. Our signaling protocols can easily be fixed to live with even higher loss at lower cost. Thats why i am suggesting to separate solution spa

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

On Wed, Aug 12, 2015 at 7:17 AM, Mikael Abrahamsson 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 pr

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

On Tue, 11 Aug 2015, Alia Atlas wrote: 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

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

On Tue, 11 Aug 2015, Pat (Patricia) Thaler wrote: Without guidance on how good the multicast packet loss rate should be, it is difficult to define the best solution . I'd say most applications people actually use start behaving very badly around 0.1 - 1% packet loss. VoIP MOS goes down, TCP s

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

On Wed, Aug 12, 2015 at 5:20 AM, Alia Atlas 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 the

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

Hi Lorenzo, On Tue, Aug 11, 2015 at 11:16 PM, Lorenzo Colitti wrote: > On Wed, Aug 12, 2015 at 11:54 AM, Alia Atlas wrote: > >> ECMP is critical in the datacenter and backbone because those networks >>> are designed to provide the E ("equal") in ECMP. Because the links are >>> equal, it's easy

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

On Wed, Aug 12, 2015 at 11:54 AM, Alia Atlas wrote: > ECMP is critical in the datacenter and backbone because those networks are >> designed to provide the E ("equal") in ECMP. Because the links are equal, >> it's easy to load-balance over them without needing to do complicated stuff >> like traf

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

Hi Lorenzo, On Tue, Aug 11, 2015 at 8:47 PM, Lorenzo Colitti wrote: > On Wed, Aug 12, 2015 at 2:47 AM, Alia Atlas wrote: > >> ECMP is critical in the data-center and backbone, but I'm interested in >> seeing what the reasoning is as to why it isn't or is needed in the homenet >> scenarios. >> >

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

Probably doesn't come as a surprise. :-) Dino > On Aug 11, 2015, at 7:24 PM, Lorenzo Colitti wrote: > >> On Wed, Aug 12, 2015 at 11:23 AM, wrote: >> You and I tunnel to each other. We pay no one and we talk to each other >> without any coordination from anyone else. If I want some DoS mitigat

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

> Ok, but that forces you to tunnel all traffic through an out-of-home tunnel > endpoint point, which is sort of a non-starter for This would be only external traffic. For traffic inside of the home you use an IGP with host route support so one address can move across subnets inside the home.

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

On Tue, 11 Aug 2015, Ole Troan wrote: Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the

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

> On Aug 11, 2015, at 5:47 PM, Lorenzo Colitti wrote: > > Having a homenet load-balance Internet-bound across multiple provides is a > non-starter because it is presumed that said providers will employ BCP38 > filtering. It's possible for the *hosts* to load-balance across different > provid

[homenet] ECMP litterature

Could anyone point me to some good publications about the tradeoffs involved in ECMP and that contains experimental data? Not necessarily on wireless. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

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

> The concerns about wifi links interfering with each other is interesting. > I wonder if that is always a local decision for one end of the links or > whether a link from A to B and one from C to D would need to be > coordinated? I'm tempted to want a nice abstraction layer, but I also > sense tha

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

> One of the requirements of homenet is that you don’t modify the hosts More precisely, Homenet must not *require* host modifications. Having features that yield better behaviour or performance for modified hosts is hopefully allowed -- otherwise, we might as well give up on source-specific routi

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

Hi Michael, Juliusz, & Pascal, Thanks for your thoughts. I understand about the different upstream providers. However, inside the home, if there are multiple paths, I can also picture it being useful to use them (backups to a NAS, multiple video streams, etc). Whether they are simply equal-co

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

On 8/11/15, 5:17 PM, "homenet on behalf of Juliusz Chroboczek" wrote: >> I am interested to learn what people think about whether equal-cost >> multi-path routes are needed in homenet. Given the previous discussion >> about parallel wireless links - which I know I have in my house and >>can't >

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

Joe, I'm mainly concerned in this discussion on what error rate is needed for acceptable performance of the protocols that support IPv6 - e.g. DAD, RA. Streaming multimedia is a separate discussion since different solutions might apply to it. > While I agree with your conclusion, what's the

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

On 8/11/2015 2:44 PM, Pat (Patricia) Thaler wrote: > RE: RFC3819 > >> The assumption is that L2 will do a reasonably good and efficient job of >> multicast/broadcast - certainly better than L3 or other layers would. > > What I think Juliuz is trying to point out is that the RFC doesn't > talk a

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

I don't think that ECMP is useful/interesting *within* the Homenet. It is certainly true that having two DSL links "bonded" is regularly done (usually using MPPP), but that presents as a single link. Some will want two CPE routers for reasons of redundancy on their multi-path uplink. My opinion

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

I think it is useful for ieee-ietf-co...@ietf.org to be in the conversation. Some of the participants in the discussion are on that reflector and I don’t know that they are on homenet or mboned. Pat From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org

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

RE: RFC3819 > The assumption is that L2 will do a reasonably good and efficient job of > multicast/broadcast - certainly better than L3 or other layers would. What I think Juliuz is trying to point out is that the RFC doesn't talk about how good the performance of L2 multicast needs to be - for

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

> I am interested to learn what people think about whether equal-cost > multi-path routes are needed in homenet. Given the previous discussion > about parallel wireless links - which I know I have in my house and can't > use - I've been wondering if these have been considered. As Toerless noted, s

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

> RPL enables non-equal cost multipath, Could you please point out the place in the spec where it is described? > That's called feasible successors in EIGRP. Er, no. Feasible successors are something different. -- Juliusz ___ homenet mailing list ho

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

On 8/11/2015 10:34 AM, Juliusz Chroboczek wrote: > I'm removing from CC the people who I know are on Homenet, please do the > same with the other lists. > >> Since RFC 3819 is mostly concerned about avoiding receiving unwanted >> multicast, >> >> I don't know why you would get that impre

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

I'm removing from CC the people who I know are on Homenet, please do the same with the other lists. > Since RFC 3819 is mostly concerned about avoiding receiving unwanted > multicast, > > I don't know why you would get that impression. I helped write that > section (as noted in sec 19). N

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

RPL enables non-equal cost multipath, Alia. That's the reasonable thing (a MUST if you ask me) to do with wireless connectivity when delivery is statistical and metrics can only provide a limited approximation of transmission chances. Any DV can do that easily so we should be able to do it with

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

I think the right term is "multiple WAN paths". There may only be a single SP offering useful service and you just need more bandwidth so you have two links to the SP. Any homenet solution where the local address is taken into account should work as well as it would with different providers. Ak

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

https://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 may be of interest in understanding some of the issues with IPv6 and wifi. Regards, Alia On Tue, Aug 11, 2015 at 12:30 PM, Toerless Eckert wrote: > Sure... > But don't look at me, i don't remember i added that Cc:, i added mbo

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

> I am interested to learn what people think about whether equal-cost > multi-path routes are needed in homenet. Given the previous discussion about > parallel wireless links - which I know I have in my house and can't use - > I've been wondering if these have been considered. > > ECMP is crit

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

> Your document describes (in my opinion) desireable behaviour for devices > going forward. I would like to see text for DHCPv6 as well, both IA_NA and > IA_PD, if the same kind of behaviour can work there somehow. This is out of > scope for homenet though. the rule applies regardless of how th

[homenet] question: equal-cost multipath?

I am interested to learn what people think about whether equal-cost multi-path routes are needed in homenet. Given the previous discussion about parallel wireless links - which I know I have in my house and can't use - I've been wondering if these have been considered. ECMP is critical in the dat

Re: [homenet] Moving forward.

-Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Dino Farinacci Sent: Tuesday, August 11, 2015 12:22 PM To: Michael Richardson Cc: HOMENET Subject: Re: [homenet] Moving forward. >And fuckin ARP and ND don’t have to go everywhere. +1. ARP and ND should st

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

Sure... But don't look at me, i don't remember i added that Cc:, i added mboned ;-)) On Tue, Aug 11, 2015 at 12:15:49PM -0400, Alia Atlas wrote: > Can we please remove ieee-ietf-co...@ietf.org from this conversation? > Once we as the IETF figure out what to write down and discuss, that'll be a >

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

On Mon, Aug 10, 2015 at 09:39:43AM +, Stephens, Adrian P wrote: > The only thing IETF can do is to use less multicast, and the obvious way of > solving it is to just replicate into unicast. This seems like a suboptimal > way to work around the problem if there are a lot of nodes. When replac

Re: [homenet] Moving forward.

> Dino Farinacci wrote: >>> WiFi is build on the assumption that single SSID is singe IP subnet >>> and that stations can roam between AP's without loss of connections. I >>> think this is great. > >> We can do this today when LISP runs on the device. And you only need a >> single IPv6 address!

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

Can we please remove ieee-ietf-co...@ietf.org from this conversation? Once we as the IETF figure out what to write down and discuss, that'll be a good time to interact, but I think this conversation is really not the point of that list. It's already cc'd to mboned and homenet... Thanks, Alia On

Re: [homenet] Moving forward.

Dino Farinacci wrote: >> WiFi is build on the assumption that single SSID is singe IP subnet >> and that stations can roam between AP's without loss of connections. I >> think this is great. > We can do this today when LISP runs on the device. And you only need a > single IPv

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

On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert) wrote: > Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 > mechanisms or not. > > If not, a router learns from MLD the state it needs to figure to which > devices it should copy a given packet. Well, th

Re: [homenet] Moving forward.

> > >> Whilst not wanting to de-rail any effort to standardise Babel > > >> (since I firmly believe it should be standardised), I'd like to > > >> hear the WG's view on having part of our Homenet stack be on > > >> Experimental Track instead of PS. E.g., would it affect vendors' > > >> willingnes

Re: [homenet] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt

On Mon, 10 Aug 2015, Fred Baker (fred) wrote: This is actually being discussed in 6man, as the chairs requested it there, but homenet might have comments to pass along. From my point of view, homenet was designed to allow things to work without hosts having the functionality described in you

Re: [homenet] Moving forward.

* Sander Steffann > > Op 10 aug. 2015, om 10:23 heeft Erik Kline het > > volgende geschreven: > > > >> Whilst not wanting to de-rail any effort to standardise Babel > >> (since I firmly believe it should be standardised), I'd like to > >> hear the WG's view on having part of our Homenet stack b

Re: [homenet] Moving forward.

Hi, > Op 10 aug. 2015, om 10:20 heeft Lorenzo Colitti het > volgende geschreven: > > Personally I doubt that in the market segment we're talking about (which > includes many vendors that just take open source implementations, integrate > them, and ship them) vendors will understand or care ab