Just to be clear, the request I filed below is only to measure the latency for these packets. The goal is to provide an approximation for some EFT variables. The value returned does not even need to come from multicast packets. For instance, in Wi-Fi, measuring the receipt-through-first-transmission duration of unicast packets would be an equivalent indicator.

The idea here is to offer the router distinct latency views of access to the medium and each peer. For each peer, the total link latency will be (latency of access to the medium scaled by expected latency of retransmission to that peer). The first term of that clause was my intended goal, and might be well approximated by an exponential moving weighted average of forwarding time of multicast/broadcast packets.

Hopefully some of those concepts will help to shape the motivation discussion.

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Joe Macker
Sent: Wednesday, September 14, 2011 11:59 AM
To: Stan Ratliff
Cc: manet@ietf.org
Subject: Re: [manet] DLEP and broadcast/multicast

I realize there are some specific sub areas being discussed here but I also feel lower layer wireless designs will have more general performance and flow control issues related to multicast/broadcast interaction.

I think we could author some core framework in this area that could be useful.  A requirements/motivation discussion might be a good first step.


> Vikram,
> 
> Yes, there is interest amongst the DLEP co-authors to include broadcast/multicast. Do you have any specific ideas?
> 
> Regards,
> Stan
> 
> On Sep 14, 2011, at 12:45 PM, Vikram KAUL wrote:
> 
>> 
>> Reviving this old thread....
>> 
>> Is there any interest in the details of the messages below. I believe that the specifications would be more complete if we include some version of broadcast/multicast.
>> 
>> Perhaps the dlep_tools software could also be modified to handle the upgraded specifications as a proof of concept
>> 
>> Vikram
>> 
>> On Mon, 15 Aug 2011, A. Riley Eller wrote:
>> 
>>> Date: Mon, 15 Aug 2011 10:01:47 -0700
>>> From: A. Riley Eller <reller@cococorp.com>
>>> To: Vikram KAUL <vkaul@research.telcordia.com>,
>>>   "manet@ietf.org" <manet@ietf.org>
>>> Subject: RE: [manet] DLEP and broadcast/multicast
>>> Perhaps the DLEP specification would benefit from accepting a pseudo-link identifier for multicast messages?
>>> 
>>> My team's research shows that EFT implementations achieve higher overall accuracy by measuring multicast messages as a universal estimator for queuing-plus-congestion. Giving DLEP the ability to describe that value, and also gaining the ability to control the radio's performance for multicast traffic, would be a valuable addition.
>>> 
>>> 
>>> -----Original Message-----
>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Vikram KAUL
>>> Sent: Monday, August 15, 2011 8:15 AM
>>> To: manet@ietf.org
>>> Subject: [manet] DLEP and broadcast/multicast
>>> 
>>> 
>>> Folks
>>> 
>>> I have some questions about how DLEP handles multicast/broadcast traffic
>>> and the intents that the router might have to send to the modem device.
>>> Some of this might have been answered; but I couldn't find it in the
>>> archives
>>> 
>>> The inherent nature of DLEP seems focused on neighbor relationships and
>>> link characteristics (MDR, CDR, Latency, etc) are focused on individual
>>> neighbors as identifed by the 'MAC Address Sub-TLV' which is mandatory in
>>> most of the messages
>>> 
>>> My question is related to broadcast and/or multicast traffic that would
>>> emanate from a router. Let us presume that the underlying multicast
>>> protocol is SMF for ease of discussion... but it could be anything that
>>> forwards native multicast packets, either via flooding or after creating
>>> trees.
>>> 
>>> How can one use DLEP to specify the MDR/CDR or latency requirements for
>>> those flows ? Is it even possible to do so ? I understand how one could do
>>> it for individual links to neighbors. But if I presume that multicast and
>>> broadcast is the predominant traffic (say 70%-80%, and I don't believe I
>>> am wrong about that), how can one use DLEP   "Link Characteristics Request
>>> Message" to specify that traffic to a particular MAC address should be
>>> able to get at least what is specified by the CDR Sub-TLV
>>> 
>>> Typically (but not always) MAC addresses for multicast IP packets are set
>>> to  01:00:xx:yy:zz:aa for a destination multicast address of xx.yy.zz.aa.
>>> Could one not have that 01:00:xx:yy:zz:aa MAC Address Sub-TLV so that the
>>> modem could identify that traffic to that MAC Address (and hence traffic
>>> to that destination multicast IP address) needs to get at least that data
>>> rate. How the modems would achieve that is a separate question, but DLEP
>>> does not delve into those answers anyway
>>> 
>>> Again, it might be that the charter for DLEP is to focus specifically on
>>> one-to-one relationships (and hence one-to-one specifications and
>>> conditions). Could the specs not be augmented to support something on
>>> one-to-many specifications ? Just thinking aloud.
>>> 
>>> regards..
>>> Vikram
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>> 
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet