Subject: [homegate] Homegate and Multicast

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 06:27:52 -0400

I have been wading through all of this, and was surprised to see no  
mention
of multicast in

<http://trac.tools.ietf.org/bof/trac/raw-attachment/wiki/WikiStart/HomeGate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pdf 

A blow to the first round of multicast deployments (almost a decade  
ago now!) was the inability of
most of the then current home routers to support things such as IGMP  
proxying. If the IETF is going to specify a
new effort to specify home gateways, then in my opinion this  
specification should support at least SSM multicast reception properly.

Supporting multicast in the home environment is becoming common in  
video deployments, but the end user typically
does not see this on their home network and there is very little  
multicast support to the end user (instead of just to their set top  
boxes). However,
the trend in the industry is towards merging the reception of
Internet-transported video and provider-transported video into common  
hardware platforms. Internet video
would certainly benefit from support of multicast reception, and there  
seems to be a recognition of that in the industry. The CableLabs  
document "IPv4 and IPv6 eRouter Specification"
http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf

states as their goal :

The specification defines a) CPE provisioning with IPv4 and IPv6  
addresses, b) IPv4 data forwarding with NAPT
and IPv6 data forwarding, c) Ability to forward IP Multicast traffic  
and d) Preserving IP QoS markings on IP data
to and from the CPE devices.

and includes sections on IGMP proxing as well as v4 and v6 multicast  
support. The other two documents mentioned as
parallel efforts :

Broadband Forum TR-124 defines a set of modular functional  
requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf 
.

The Home Gateway Initiative also has a Home Gateway Requirements:  
Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf 
.

also include multicast support.

So, while I support this effort, I would like to see multicast SSM  
added to Theme 1.

Regards
Marshall

P.S. Can I also suggest that what is basically a text file BOF charter  
should be served as a text file in the usual
fashion ?

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 Jun 2009 14:02:43 +0300

On 2009-6-16, at 13:27, Marshall Eubanks wrote:
> should be served as a text file in the usual fashion ?

Feel free to also use the TSV area wiki: http://trac.tools.ietf.org/area/tsv/trac/wiki

I've created an empty page for you at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

Lars

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 16 Jun 2009 10:02:25 -0400

Speaking from experience with regards to eRouter, while we had "some" use cases to incorporate SSM multicast into eRouterv1.0, we didn't have the use cases that have emerged more recently. I'd agree that we need to define multicast mechanisms (IGMP and MLD) and could reference existing specifications for this effort, but we'll need to think first on the aforementioned use cases long and hard. While IP video content delivery is an emerging technology with many advocates and interested parties, it can be difficult to sort through which use cases are realistic and which are only exercises in theory.
 
-KE 

________________________________

From: [email-masked] on behalf of Marshall Eubanks
Sent: Tue 6/16/2009 4:27 AM
To: [email-masked]
Cc: Greg Shepherd; Leonard Giuliano
Subject: [homegate] Homegate and Multicast

states as their goal :

Regards
Marshall

_______________________________________________
homegate mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homegate

P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.

This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Jun 2009 16:11:59 +0200

On 16 jun 2009, at 16:02, Erichsen, Kirk wrote:

> While IP video content delivery is an emerging technology with many  
> advocates and interested parties, it can be difficult to sort  
> through which use cases are realistic and which are only exercises  
> in theory.

Speaking of that: multicast streaming doesn't work over wifi. A lot of  
home gateways talk to the local hosts over wifi. How do we solve this?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 16 Jun 2009 10:15:02 -0400

If one is discussing IPv6 mcast, see section 7.2 for mcast specification
in the IETF v6ops IPv6 CPE Router document at the URL below.  Sorry, I
didn't get time yet to catch up with all the emails yet.

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-00.
txt

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erichsen, Kirk
Sent: Tuesday, June 16, 2009 10:02 AM
To: Marshall Eubanks; [email-masked]
Cc: Greg Shepherd; Leonard Giuliano
Subject: Re: [homegate] Homegate and Multicast

Speaking from experience with regards to eRouter, while we had "some"
use cases to incorporate SSM multicast into eRouterv1.0, we didn't have
the use cases that have emerged more recently. I'd agree that we need to
define multicast mechanisms (IGMP and MLD) and could reference existing
specifications for this effort, but we'll need to think first on the
aforementioned use cases long and hard. While IP video content delivery
is an emerging technology with many advocates and interested parties, it
can be difficult to sort through which use cases are realistic and which
are only exercises in theory.
 
-KE 

<http://trac.tools.ietf.org/bof/trac/raw-attachment/wiki/WikiStart/HomeG
ate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pdf 

states as their goal :

Broadband Forum TR-124 defines a set of modular functional 
requirements for broadband residential
gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf
.

The Home Gateway Initiative also has a Home Gateway Requirements: 
Residential Profile
document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residenti
al.pdf
.

Regards
Marshall

P Go Green! Print this email only when necessary. Thank you for helping
Time Warner Cable be environmentally responsible.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 10:20:53 -0400

> I've created an empty page for you at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

That's fine, but what I was really suggesting was that charter  
revisions should be sent to the list as
text.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 10:17:33 -0400

On Jun 16, 2009, at 10:02 AM, Erichsen, Kirk wrote:

> Speaking from experience with regards to eRouter, while we had  
> "some" use cases to incorporate SSM multicast into eRouterv1.0, we  
> didn't have the use cases that have emerged more recently. I'd agree  
> that we need to define multicast mechanisms (IGMP and MLD) and could  
> reference existing specifications for this effort, but we'll need to  
> think first on the aforementioned use cases long and hard. While IP  
> video content delivery is an emerging technology with many advocates  
> and interested parties, it can be difficult to sort through which  
> use cases are realistic and which are only exercises in theory.
>

I fully agree. Note that many home uses have a 802.11 WLAN on the  
"home" side of the gateway, and many
home 802.11 access points do not do multicast well, or at all.

Of course, if the gateway hardware does not support it, all use cases  
are likely to remain academic.

Regards
Marshall

> P Go Green! Print this email only when necessary. Thank you for  
> helping Time Warner Cable be environmentally responsible.
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 10:34:37 -0400

On Jun 16, 2009, at 10:11 AM, Iljitsch van Beijnum wrote:

> Speaking of that: multicast streaming doesn't work over wifi. A lot  
> of home gateways talk to the local hosts over wifi. How do we solve  
> this?

Multicast does work over 802.11.  The trouble is that many access  
points don't do IGMP/MLD, so any multicast present on the wireline  
side of the LAN is flooded to the wireless. In an enterprise  
environment (with a faster LAN than WLAN, and potentially lots of  
multicast users), this has the risk to totally flood the 802 WLAN with  
unintended traffic. As a result, a lot of access points limit or block  
multicast by default.

It is not clear to me that that is as much of an issue in a home  
environment (where the WLAN is much faster than the link to the  
outside, and it is unlikely that there is also a wireline LAN with a  
lot of multicast traffic on it).

Saying that the Gateway should run IGMP/MLD might be enough to resolve  
this.

Regards
Marshall

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 16 Jun 2009 10:34:53 -0400

I haven't heard that. Is that a "should work" but doesn't due to common flaws in implementation, or "cannot work" because of a flaw in the WiFi specs? It would be out of scope if it's a question of the WiFi spec.
 
-KE

From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Tue 6/16/2009 8:11 AM
To: Erichsen, Kirk
Cc: Marshall Eubanks; [email-masked]; Greg Shepherd; Leonard Giuliano
Subject: Re: [homegate] Homegate and Multicast

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 10:40:45 -0400

On Jun 16, 2009, at 10:34 AM, Erichsen, Kirk wrote:

> I haven't heard that. Is that a "should work" but doesn't due to  
> common flaws in implementation, or "cannot work" because of a flaw  
> in the WiFi specs? It would be out of scope if it's a question of  
> the WiFi spec.
>

No, it works fine, it's just that most Access Points have to flood the  
traffic, so many (most?) limit or
block it by default. (Apple Airports used to limit multicast to 1 Mbps  
out of the box, for example, but
of course you could change it if you wanted to.)

Of course, when you are talking about home deployments, anything that  
requires people to change default
settings on their gateways to do something will eliminate 95% or more  
of the market.

See my other message on this for more details.

Regards
Marshall

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 16 Jun 2009 10:43:38 -0400

Some more thought has to be given to video over WiF because WiFi spans
my neighbor's home too and if the home router is not well secured and
managed, my video over WiFi goes to the neighbor's home as well.  The
video delivery has to be planned too because if cable operators send
broadcast quality TV video to a home, the video channel is encrypted and
theft safe.  Such encryption mechanisms may not exist with IPTV or local
video running in home including over wireless. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erichsen, Kirk
Sent: Tuesday, June 16, 2009 10:35 AM
To: Iljitsch van Beijnum
Cc: [email-masked]; Greg Shepherd; Leonard Giuliano
Subject: Re: [homegate] Homegate and Multicast

I haven't heard that. Is that a "should work" but doesn't due to common
flaws in implementation, or "cannot work" because of a flaw in the WiFi
specs? It would be out of scope if it's a question of the WiFi spec.
 
-KE

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 16 Jun 2009 10:41:47 -0400

Marshall,
 
I caught up with your multicast thread. This looks thoroughly resolvable with a modicum of explicit behavioral definition and should apply, as you've stated below and elsewhere, regardless of the LAN side interface the mcast will traverse. On the important point of "defaults," we should define these such that we do not require extensive reconfiguration by the professional installer or end user/customer, consistent with the view that all such changes to advanced functionality tend to incur user error (which can be worse than not working at all) or at the very least limit the use of the functionality substantially. 
 
-KE

From: Marshall Eubanks [mailto:[email-masked]]
Sent: Tue 6/16/2009 8:40 AM
To: Erichsen, Kirk
Cc: Iljitsch van Beijnum; [email-masked]; Greg Shepherd; Leonard Giuliano
Subject: Re: [homegate] Homegate and Multicast

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 10:58:48 -0400

> video running in home including over wireless.

Such encryption mechanisms do not and will not in general exist with  
Internet video. (I am talking about content encryption, not protection  
of the 802.11 itself.)

In the case of IPTV, if the provider is providing "network"  
television, then (at least in the
USA) they do insist on encryption and other protections of the streams.
In many cases this extends to requiring use of approved hardware/ 
software solutions and even bringing
engineers on-site for certification, which
suggests that, if network television is ever going to be unbundled in  
the US (as I think it will),
then the home gateway effort would have to worry about this.

Regards
Marshall

P.S. If you are interested, I can recommend the IPTV-Users list at [email-masked]

> common

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 16 Jun 2009 10:52:49 -0400

There will be a lot of detail that has to go into the use cases. Examples thrown around so far have included separate DRM strategies depending on whether the end device is a PC or an IP STB and those that rely more on wireline security and less on application layer security (i.e. DRM). Neither is full proof. To get the consent of content providers, it may be necessary (or at least to anticipate) doing a bit of both. The content providers are well aware that their value could be sapped away by a poorly implemented/poorly deployed customer gateway that lets everyone in the neighborhood get access to streams that could potentially find their way into the rouge P2P distribution nets.
 
The issue with dovetailing any IPTV strategy into this gateway effort are the high risk that we will not have broad industry consensus with regards to protocols, architecture, etc. and that will leave these answers half answered. While it is important to keep in mind, we will have to monitor other groups for activity to determine what we can borrow from and what needs longer to work itself out. As we progress and projects develop we could borrow from emerge, perhaps we could liaison into that group (or groups). Until then it's probably going to be an exercise in frustration and could easily slow our progress if we try to fully incorporate the scope IPTV delivery over a gateway with all the nuts and bolts would entail.
 
-KE

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tue 6/16/2009 8:43 AM
To: Erichsen, Kirk; Iljitsch van Beijnum
Cc: [email-masked]; Greg Shepherd; Leonard Giuliano
Subject: RE: [homegate] Homegate and Multicast

Hemant

-----Original Message-----

-KE

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 11:20:36 -0400

On Jun 16, 2009, at 10:43 AM, Iljitsch van Beijnum wrote:

> On 16 jun 2009, at 16:34, Marshall Eubanks wrote:
>
>>> Speaking of that: multicast streaming doesn't work over wifi. A  
>>> lot of home gateways talk to the local hosts over wifi. How do we  
>>> solve this?
>
>> Multicast does work over 802.11.
>
> Of course, otherwise ARP or ND wouldn't work and IP over 802.11  
> would be impossible.
>
> However, multicast _streaming_ doesn't work.
>

Sure it does. I have done this professionally, to distribute video at  
shows. You need to pay attention to your SNR, RFI, etc.

>> The trouble is that many access points don't do IGMP/MLD, so any  
>> multicast present on the wireline side of the LAN is flooded to the  
>> wireless. In an enterprise environment (with a faster LAN than  
>> WLAN, and potentially lots of multicast users), this has the risk  
>> to totally flood the 802 WLAN with unintended traffic. As a result,  
>> a lot of access points limit or block multicast by default.
>
> I've seen multicast rate limiting and the other issues that you  
> mention may also be a factor. However, the real problem is that  
> wireless is unreliable, and because there are presumably many  
> listeners, the normal ACK/retransmission mechanism isn't used for  
> broadcasts/multicasts on 802.11. So you lose many packets. Another  
> problem is that in order to make multicasts for management protocols  
> work those packets are sent at very low bitrates (1 - 6 Mbps) so  
> even a few Mbps of multicast traffic saturates the wireless channel.
>

802.11b will indeed saturate at something like 6 Mbps IIRC. Whether  
that is a very low bit rate is a matter of debate. In many instances,  
this is hard to tell. (If the bandwidth to the Internet is, say, 2  
Mbps, a 6 Mbps limit is hard to detect.) Clearly, as home Internet  
bandwidths increase, home LAN and WLAN speeds need to keep up.

The home use case is different from, say, the needs of the IETF  
meeting network and I frankly doubt a "one size fits all" solution is  
attainable.

FEC would be very useful for 802.11 multicasts, but I don't that  
Homegate should deal with Layer 3 FEC of wireless traffic. That should  
be provided by operators, streaming servers, etc.

It occurs to me as I write this that P2P is also an important home  
use, and Homegate should also
be aware of whatever comes from the ALTO / PPSP / LEDBAT efforts.

Regards
Marshall

> (BTW the 1 Mbps thing that you mention about Apple base stations  
> isn't a rate limit but the rate at which multicasts are sent AFAIK.  
> With an older Apple base station I had the situation that after  
> three or so multicasts in quick succession multicasts would be block  
> for a short time. With the newer AEBS that doesn't seem to be the  
> case anymore but I haven't extensively tested this.)
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Jun 2009 16:43:29 +0200

> Multicast does work over 802.11.

Of course, otherwise ARP or ND wouldn't work and IP over 802.11 would  
be impossible.

> wireless. In an enterprise environment (with a faster LAN than WLAN,  
> and potentially lots of multicast users), this has the risk to  
> totally flood the 802 WLAN with unintended traffic. As a result, a  
> lot of access points limit or block multicast by default.

I've seen multicast rate limiting and the other issues that you  
mention may also be a factor. However, the real problem is that  
wireless is unreliable, and because there are presumably many  
listeners, the normal ACK/retransmission mechanism isn't used for  
broadcasts/multicasts on 802.11. So you lose many packets. Another  
problem is that in order to make multicasts for management protocols  
work those packets are sent at very low bitrates (1 - 6 Mbps) so even  
a few Mbps of multicast traffic saturates the wireless channel.

(BTW the 1 Mbps thing that you mention about Apple base stations isn't  
a rate limit but the rate at which multicasts are sent AFAIK. With an  
older Apple base station I had the situation that after three or so  
multicasts in quick succession multicasts would be block for a short  
time. With the newer AEBS that doesn't seem to be the case anymore but  
I haven't extensively tested this.)

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 11:44:39 -0400

Dear Kirk;

On Jun 16, 2009, at 10:52 AM, Erichsen, Kirk wrote:

> There will be a lot of detail that has to go into the use cases.  
> Examples thrown around so far have included separate DRM strategies  
> depending on whether the end device is a PC or an IP STB and those  
> that rely more on wireline security and less on application layer  
> security (i.e. DRM). Neither is full proof. To get the consent of  
> content providers, it may be necessary (or at least to anticipate)  
> doing a bit of both. The content providers are

Some content providers, if you please. In this context you need to  
keep in mind that there are other parties at the table, many of whom  
do not view DRM as essential to their business model.

> well aware that their value could be sapped away by a poorly  
> implemented/poorly deployed customer gateway that lets everyone in  
> the neighborhood get access to streams that could potentially find  
> their way into the rouge P2P distribution nets.
>
> The issue with dovetailing any IPTV strategy into this gateway  
> effort are the high risk that we will not have broad industry  
> consensus with regards to protocols, architecture, etc. and that  
> will leave these answers half answered. While it is important to  
> keep in mind, we will have to monitor other groups for activity to  
> determine what we can borrow from and what needs longer to work  
> itself out.

I would certainly not advocate re-inventing any of these wheels. From  
what I can tell, there are a number of groups, such as the VSF/SMPTE  
one, making rapid progress on open IPTV protocols. (Open standards,  
not generally open source.) To the extent that these get industry  
acceptance, they could ride on top of the Homegate effort.

I am not aware of much, except for the support of multicast, that  
Homegate would have to do to support these
protocols. The end user might need to buy a box or a NIC card, but if  
the gateway does not need to worry about
what's going on the wire, I don't think it should.

Regards
Marshall

> As we progress and projects develop we could borrow from emerge,  
> perhaps we could liaison into that group (or groups). Until then  
> it's probably going to be an exercise in frustration and could  
> easily slow our progress if we try to fully incorporate the scope  
> IPTV delivery over a gateway with all the nuts and bolts would entail.
>
> -KE
>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 16 Jun 2009 10:08:48 -0700

I don't think it's true that multicast video is becoming common on  
home networks since it doesn't work too well on many home networks.   
It's really useful for control traffic, for things like discovery.

Mark
On 16/06/2009, at 3:27 AM, Marshall Eubanks wrote:

> Internet-transported video and provider-transported video into  
> common hardware platforms. Internet video
> would certainly benefit from support of multicast reception, and  
> there seems to be a recognition of that in the industry. The  
> CableLabs document "IPv4 and IPv6 eRouter Specification"
> P.S. Can I also suggest that what is basically a text file BOF  
> charter should be served as a text file in the usual
> fashion ?
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 13:23:12 -0400

On Jun 16, 2009, at 1:08 PM, Mark Baugher wrote:

> home networks

I didn't say that. I said that "multicast in the home environment is  
becoming common in video deployments."
Multicast is indeed common in IPTV and "switched digital video", at  
least outside of the US, but it is generally
not offered to the user directly, at least in the systems I am  
familiar with. (Some of the University IPTV deployments don't separate  
the video and user networks, and so do offer multicast to the end  
user.) Part of the
reason for that is the inability of NATs and gateways to support it,  
which this effort could do something about.

It would seem to me to be logical for the Homegate to support IPTV  
standards based on IP. Whether that requires extra work on the part of  
the gateway is what's not clear, at least to me.

Regards
Marshall

> since it doesn't work too well on many home networks.  It's really  
> useful for control traffic, for things like discovery.
>
> Mark
>> most of the then current home routers to support things such as  
>> IGMP proxying. If the IETF is going to specify a
>> and IPv6 data forwarding, c) Ability to forward IP Multicast  
>> traffic and d) Preserving IP QoS markings on IP data
>> and includes sections on IGMP proxing as well as v4 and v6  
>> multicast support. The other two documents mentioned as
>> parallel efforts :
>>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 16 Jun 2009 10:30:20 -0700

IPTV or not, the common use of multicast on home networks is for  
control not video, and it's not clear to me that this can be fixed in  
the gateway.

Mark

On 16/06/2009, at 10:23 AM, Marshall Eubanks wrote:

> familiar with. (Some of the University IPTV deployments don't  
> separate the video and user networks, and so do offer multicast to  
> the end user.) Part of the
> standards based on IP. Whether that requires extra work on the part  
> of the gateway is what's not clear, at least to me.
>
> Regards
> Marshall
>
>>> I have been wading through all of this, and was surprised to see  
>>> no mention
>>> of multicast in
>>>
>>> A blow to the first round of multicast deployments (almost a  
>>> decade ago now!) was the inability of
>>> multicast support to the end user (instead of just to their set  
>>> top boxes). However,

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Jun 2009 10:32:18 -0700

> It's really useful for control traffic, for things like discovery.

It would be very nice if people would stop assuming that the only  
interesting application of non-local scope multicast is to send live A/ 
V content efficiently.  Multicast is really only worth thinking about  
for A/V transport when the content is valuable only when it's *live*,  
because otherwise store-and-forward is more efficient, and it flows  
much better over unicast transports, e.g. TCP, SCTP, etc.

The truth is we really don't know what the interesting applications of  
non-local scope multicast will be until we have an Internet that can  
route it.  Sadly, we don't have one yet, and one of the reasons for  
that is that residential gateways, by and large, don't implement  
multicast routing protocols.

Because residential service providers won't route multicast transit.

The IPv6Ready <http://www.ipv6ready.org/> phase-2 certification  
doesn't even yet require support for a multicast routing protocol.

I don't actually think multicast is a pressing need right now or in  
the near future.  I see it becoming a pressing need in the foreseeable  
but somewhat distant future, when we have residential networks with  
zero-configuration routed subnetworks and we need non-local scope  
multicast for unmanaged service discovery, among other things.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 16 Jun 2009 07:17:55 -0700

On Tue, Jun 16, 2009 at 7:11 AM, Iljitsch van Beijnum<[email-masked]> wrote:
>> advocates and interested parties, it can be difficult to sort through which
> Speaking of that: multicast streaming doesn't work over wifi. A lot of home
> gateways talk to the local hosts over wifi. How do we solve this?

Perhaps AMT Relay/Gateway services could be incorporated into the home
gateway. It could provide AMT tunnel services to the hosts over wifi,
and additionally connect as a gateway to an upstream AMT relay in
deployments where the multicast radius does not extend down to the
home.

http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09

Greg

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Jun 2009 12:30:32 -0700

BEHAVE took a stab at this, http://tools.ietf.org/html/rfc5135

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marshall Eubanks
> Sent: Tuesday, June 16, 2009 3:28 AM
> To: [email-masked]
> <http://trac.tools.ietf.org/bof/trac/raw-attachment/wiki/WikiS
> tart/HomeGate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pdf 
>  >
> 
> document:http://www.homegatewayinitiative.org/publis/HGI_V1.01
> _Residential.pdf 
> .
>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 16 Jun 2009 12:55:13 -0700

On 16/06/2009, at 10:32 AM, james woodyatt wrote:

>
> The truth is we really don't know what the interesting applications  
> of non-local scope multicast will be until we have an Internet that  
> can route it.  Sadly, we don't have one yet, and one of the reasons  
> for that is that residential gateways, by and large, don't implement  

I expect we'll have to for IPv6 because we want site-local scope to  
work (viz. http://www.ietf.org/internet-drafts/draft-bnss-v6ops-upnp-01.txt) 
.

Mark

---

From: "Richard Bennett" <[email-masked]>
Date: Tue, 16 Jun 2009 13:16:06 -0700

Actually, the "real problem" with multicast over 802.11 is related to
acknowledgements, but isn't simply a matter of reliability or the lack
thereof. 802.11 is a multi-rate system, and it decides which rate to use for
any given association based on successful and unsuccessful transmissions.
The ACKs are important because they close a feedback loop, but MAC-level
multicast doesn't have any ACKs, so the sender doesn't know how fast to
transmit. One of the common ways around this problem - which is really a
defect in 802.11 - is to convert each multicast streams into a series of
unicasts. So instead of a multicast stream going out at 2 Mb/s, you have two
or three unicast streams at 54 (or higher, for 802.11n.) 

Some of your larger Wi-Fi chip vendors include this capability as a standard
feature in their Linux drivers (for use in home gateways.) Converting IP
multicast to Wi-Fi unicast is the classic example of a "SHOULD"
recommendation. 

Regarding the problem of jumbo frames, note that Wi=Fi has always supported
a larger-than Ethernet MSDU, 2304 bytes, and it also supports fragmentation
so it shouldn't care in principle how large your MTU is. 

The question of Wi-Fi frame sizing for performance is largely moot for
higher-level protocols in 802.11e and n, since the aggregation scheme takes
care of it, so I wouldn't worry too much about that. 

Richard Bennett

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Iljitsch van Beijnum
Sent: Tuesday, June 16, 2009 7:43 AM
To: Marshall Eubanks
Cc: [email-masked]
Subject: Re: [homegate] Homegate and Multicast

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Jun 2009 11:18:44 +0200

On 16 jun 2009, at 22:16, Richard Bennett wrote:

> One of the common ways around this problem - which is really a

This didn't make sense to me at first, because the host then would see  
unicast packets. But now I realize that this would simply send an IP  
multicast packet, and possibly even an ethernet multicast packet, as  
an 802.11 unicast packet, right?

This seems like a useful trick in a home gateway setup where we must  
assume that there may be significant interference and the number of  
hosts listening to the same multicast group probably wouldn't be too  
high.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Jun 2009 18:26:20 +0200

---

From: Mark Baugher <[email-masked]>
Date: Wed, 17 Jun 2009 09:58:56 -0700

On 17/06/2009, at 2:18 AM, Iljitsch van Beijnum wrote:

> This didn't make sense to me at first, because the host then would  
> see unicast packets. But now I realize that this would simply send  
> an IP multicast packet, and possibly even an ethernet multicast  
> packet, as an 802.11 unicast packet, right?
>

We don't do that today for setting up home gateways do we?

Mark

---

From: "Richard Bennett" <[email-masked]>
Date: Wed, 17 Jun 2009 13:18:36 -0700

Right, we convert the IP multicast to 802.11 unicast. Similar tricks are
done to adapt IP to layer 2 networks that don't support broadcast or
multicast addressing.

This technique is used in many home gateways today, as well as in most
enterprise WLAN switches. Not for doing the "setup," but for streaming to a
smallish multicast group.

Richard Bennett

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 9:59 AM
To: Iljitsch van Beijnum
Cc: Richard Bennett; [email-masked]
Subject: Re: [homegate] Homegate and Multicast

Mark