On Mon, Aug 10, 2015 at 10:16:04AM -0700, james woodyatt wrote:
An additional complication with 802.11 is that various physical encodings use
spacial beam forming for unicast and that???s not possible with multicast.
It???s the main reason that transmission bit rates for unicast can be so
The default is 600s, not 60s.
Ouch.
(And thanks for the correction.)
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Such a thing is just untrue. IP works on any link, it has to. That's why
we do IP over Foo.
Agreed, IP is supposed to work on anything from 10Gb/s fiber to carrier
pigeons. The market has chosen, IP has eaten all of the protocols that
required special support from the link layer. If a link
On Aug 6, 2015, at 17:42, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
I wasn't aware of the treatment of multicast packets as less than best
effort in wireless transmission. That is not exactly intuitive, given
that radio is inherently broadcast.
Yes, that's
https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00
Something that homenet, and specifically HNCP, might be interested to consider
is the impact of egress/SADR routing as discussed in this draft on its
recommendations. The draft is in WGLC and in need of a revised draft, so you
On Aug 10, 2015, at 12:02 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
I'm not sure if I read you right, but I assume you are concerned about
what happens when a delegated prefix is retraceted. (The ISP stops the
delegation, or the DHCPv6-PD client decides to hide the
Fred,
Add another LAN interface to Alice, connecting host Porky.
If Alice didn’t advertise both ISP-Alice and ISP-Bob prefixes, Porky couldn’t
use ISP Bob.
It would be a quite complicated set of rules determining when Alice should or
should not include ISP Bob’s prefixes on a given link. I’m
On Aug 10, 2015, at 10:28, Fred Baker (fred) f...@cisco.com wrote:
If every router is responsible to announce prefixes from ISP-Alice and
ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a
packet to ISP-Alice, it will send it to ISP-Bob, who will then have to
On Aug 10, 2015, at 1:05 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Such a thing is just untrue. IP works on any link, it has to. That's why
we do IP over Foo.
Agreed, IP is supposed to work on anything from 10Gb/s fiber to carrier
pigeons. The market has chosen, IP
On 10/08/2015 08:32, Lorenzo Colitti wrote:
Chairs - what do you think would happen if you called rough consensus on
babel based on the maturity of the running code? Is it even a practical
possibility for you to do so, or is that option out of your reach for as
long as the design team
On Mon, Aug 10, 2015 at 5:08 PM, Ray Bellis r...@bellis.me.uk wrote:
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.
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
Hello Mikael,
Please see my responses embedded below...
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +1 (971) 330 6025 (mobile)
--
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers
sorry, address typo. again.
IMHO, a better place for this discussion than homenet is Mboned,
for example in conjunction with evolving
draft-mcbride-mboned-wifi-mcast-problem-statement.
I do not particularily like the scope either of the discussion in homenet
or in the draft in MBoned, because
Hmm... the multicast to unicast conversion described in there looks fairly
weak. It doesn't discuss any problems with IGMPv2/MLDv1 wrt to report
suppression and how to deal with that for example. Or the challenge that
hosts may not be happy about receiving IP multicast packets with unicast MAC
This is a nice start for what i'd call poblem 2): making
multipoint delivery of serious amount of data to more receivers more
reliable. Would love to understand if there is any definition of how
this would or could be used for actual IP multicast, eg: where
is the definition of using IGMP
I am delighted to see a cross layer conversation on wifi finally
taking place here. I gave a talk at last weeks battlemesh about a few
of the things in the pipeline to improve it:
https://plus.google.com/u/0/107942175615993706558/posts/W5tynWhK8v1
The fun part, where I lay out one of the big
On Sat, Aug 8, 2015 at 11:00 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
I'm confused again. PIO lifetimes are on the order of hours, or even
days, while unsolicited RAs are sent every 60s. Plus there's nothing
preventing you from sending them more often.
The default is
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
On Mon, 10 Aug 2015, Henning Rogge wrote:
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
IMHO, a better place for this discussion than homenet is Mboned,
for example in conjunction with evolving
draft-mcbride-mboned-wifi-mcast-problem-statement.
I do not particularily like the scope either of the discussion in homenet
or in the draft in MBoned, because both only look at the
(included mbo...@ietf.org and also changed subject to something more
appropriate)
As far as I can tell, so far people have told IETF it's their job to
reduce multicast to make IP based protocol work on 802.11 media. That's
at least what I have been seeing. Considering the reactions from
On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
The question in my mind is whether this discussion thread is uncovering any new
requirements for the 802.11 standard.
Thanks for the summary, it seems correct.
It might not need new 802.11 standards, but we still have an operational
problem in
Hello all,
Let me summarise some of the characteristics of the 802.11 standard related to
multicast:
1. The basic packet error rate (before Ack) designed to is 10% in the case
of unicast. This is a very broad statement and almost so
simplistic as to be misleading.Errors are composed of
On Mon, Aug 10, 2015 at 4:02 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
[...]
There are two lessons to be drawn from that experience:
1. don't put 1500 wifi routers in a single room;
2. making a routing daemon that works well in a variety of conditions is
hard
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:
From what I read below, one way out of this is the IETF making a clear
statement that multicast is an integral part of IP networking, and if a
medium doesn't support delivering multicast frames in a similarily reliable
fashion to unicast,
From what I read below, one way out of this is the IETF making a
clear
statement that multicast is an integral part of IP networking, and if
a medium doesn't support delivering multicast frames in a similarily
reliable fashion to unicast, it's not suited to carrying IP based
protocols
On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
[Adrian P Stephens]
This problem is nothing new. We know about the relative performance of
multicast vs unicast.
Saying it sucks is not very helpful. Unlicensed spectrum is free. You are
getting more than you are paying for :0).
I don't see
Pascal:
On Mon, Aug 10, 2015 at 10:05:54AM +, Pascal Thubert (pthubert) wrote:
The basic APs will apply rules like 'oh, we do not expect a router on Wi-Fi
so let's drop all RS towards wireless'. Hardcoded in the box.
Clearly, a behavior like this that is not backed by a standard,
Hello Mikael
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.
Many products do that. But then people immediately think about
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:
Yes it is. IP over Foo must indicate if IP multicast over a link uses L2
mechanisms or not.
Ok, so am I interpreting you correctly that there are three profiles for
L1/L2 mediums:
1. Multicast works approximately the same way as
Folks, please trim your cc: lists - you're exceeding the limit that
Mailman permits and I don't intend to increase it (nor pass through any
messages already blocked as a result).
thanks,
Ray
___
homenet mailing list
homenet@ietf.org
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:
Unsure about your profile, Mikael. Ethernet would be a #2 by now, only
things like sat-links could still be #1s. So the work would really be to
I don't agree, wired ethernet is still #1 if you ask me.
figure out what to do with the
To come back on the discussion why mcast matters for IPv6 while bcast does
not for IPv4:
- IPv6 uses heavily mcast while in IPv4 (ND is quite chatty)
- IPv6 uses many more addresses than IPv4 (hence even more chatty)
A couple of us running very large (more than 1 STA) WiFi network have
Unsure about your profile, Mikael. Ethernet would be a #2 by now, only things
like sat-links could still be #1s. So the work would really be to figure out
what to do with the varieties of your #2. My question is rather whether IP over
802.11 should be operated like IP over Ethernet or like IP
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
This is actually being discussed in 6man, as the chairs requested it there, but
homenet might have comments to pass along.
Begin forwarded message:
From: internet-dra...@ietf.org
Subject: I-D Action: draft-baker-6man-multi-homed-host-00.txt
Date: August 7, 2015 at 7:40:43 AM PDT
To:
37 matches
Mail list logo
