There is a WG item in v6ops WG which tells the Access Point should
unicast RAs to battery-powered Clients rather than multicasting it,
because the observation is that it consumes power on the smartphone.
That's an observation reflected in more places.
The solution space is the following:
-
Le 12/08/2015 07:17, Mikael Abrahamsson a écrit :
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
On Aug 12, 2015, at 21:35, Henning Rogge hro...@gmail.com wrote:
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
On 8/13/2015 10:59 AM, james woodyatt wrote:
On Aug 12, 2015, at 21:35, Henning Rogge hro...@gmail.com
mailto:hro...@gmail.com wrote:
...
If you have a duplicate MAC then DAD will not safe you... you cannot
communicate anyways because of a layer-2 problem.
Yes, and DAD also has logic that
On 8/12/2015 12:39 PM, Henning Rogge wrote:
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.,
On Thu, 13 Aug 2015, Henning Rogge wrote:
If you have a duplicate MAC then DAD will not safe you... you cannot
communicate anyways because of a layer-2 problem.
Well, you can share the same L3 network but not share the same L2 network
(and do proxy-ND between them). But yes, you're basically
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,
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
On 12/08/15 07:51, homenet on behalf of Henning Rogge
homenet-boun...@ietf.org on behalf of hro...@gmail.com wrote:
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
On Wed, 12 Aug 2015, Henning Rogge wrote:
0.1% multicast packet loss is unrealistic.
I found this interesting document:
https://hal.archives-ouvertes.fr/tel-00919403/document
In 2.4 there is a lot of text about different ways of making multicast
(more) reliable.
From what I can see, the
On 8/11/2015 3:32 PM, Pat (Patricia) Thaler wrote:
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
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
On 8/12/2015 1:12 AM, Mikael Abrahamsson wrote:
Multicast packets should be delivered with less than 1% packet loss
Multicast packets should be delivered within 200-500ms (for instance DAD
requires answer within 1s)
That assumes default DAD configuration, and I already noted that this is
] On Behalf Of
Alia Atlas
Sent: Tuesday, August 11, 2015 9:16 AM
To: Toerless Eckert
Cc: mbo...@ietf.org; Homenet; ieee-ietf-co...@ietf.org
Subject: Re: [ieee-ietf-coord] [homenet] Multicast on 802.11
Can we please remove ieee-ietf-co...@ietf.orgmailto:ieee-ietf-co...@ietf.org
from
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).
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 impression. I
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
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
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
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, the
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
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 eck...@cisco.com wrote:
Sure...
But don't look at me, i don't remember i added that
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 about how
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
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
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 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
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
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
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
37 matches
Mail list logo
