Subject: Re: mboned: Country level Admin scope

From: "Kevin C. Almeroth" <[email-masked]>
Date: Fri, 7 May 2004 08:14:55 -0700

>>wouldn't it be easier to embed the bandwidth in the sdp file or other oob 
>>source discovery mechanism and let the clients deal with that. after all 
>>I'm currently free to request a 500Kb/s unicast udp stream over my 256K 
>>dsl connection and what I get is packet loss. 

While I agree that "WWUD" is a perfectly fine question, the practicality
is that if a user on the wireless link at the IETF suddenly started
consuming a multi-megabit per second stream of unicst traffic, they would 
be shut off and traffic from the IP of the source filtered.

So, yes, unicast does have the same problem and no real solution, but 
telling the unicast world to solve that problem first is not a solution
that will every fly.

Introducing multicast into the net, by default, creates problems that
didn't exist before.  In other words, I often say WWUD, but there are
exceptions.

It should be obvious to see that this is a problem that isn't going to 
be solved.  And so every single wireless network will either come with
multicast turned off (by default) or network admin will go through one 
of the IETF-like episodes of lots of collisions and turn multicast off.  
And so in 5 years we'll have wireless all over the place but with no 
multicast.  Carrying it one step further:  and in 5 years we'll have
mboned talking about how to create a tunnelling protocol to get 
multicast onto the wireless network.

-Kevin
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 07 May 2004 13:47:43 -0400

On Fri, 7 May 2004 08:14:55 -0700
> of the IETF-like episodes of lots of collisions and turn multicast off.

Dear Kevin;

Of course, during the SLC IETF when I think wireless multicast was first turned
on and then turned off, it was pretty apparent to me that multicast was neither
the cause of the problems, nor did turning it off fix them. 
  
> multicast onto the wireless network.

I think that wireless Ethernet is likely to move towards MANET like solutions, such
as AODV - i.e., to routed networks instead of "flat Earth's". 
I have recently gotten interested in this issue, and there is a Multicast AODV and
there is some bibliography at

http://snow.icu.ac.kr/korykang/refs/adhoc.html

I see no reason why a dynamically routed wireless 
network could not handle multicast sensibly and prevent flooding, so all is not lost if they
are built right. I have not delved into this deeply enough yet to have an opinion as to
whether they have. 

Of course automatically filtering flows based on bandwidth usage is another matter. 
I do not like the idea of overlaying this into the group address much. I know that unicast
webcasts using UDP will have the same problem - the question to me is whether this should driven
into the routing layer at all.

Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 7 May 2004 11:23:52 -0700

>> multicast onto the wireless network.

    Kevin, I don't see any other way then these two alternatives:

    o Have the WiFi network implement a VLAN-type capability, where unicast
      traffic goes on 1 VLAN using one WiFi channel and multicast traffic
      goes on the other VLAN on a different WiFi channel. Then you can
      natively multicast. 802 standarization work would have to be done here
      most likely

    o Use AMT and unicast multicast frames, the endpoints of the auto-tunnel
      could either be at the first-hop router on the WiFi net or deeper
      into the topology.

Dino