Subject: Re: [manet] DLEP and broadcast/multicast

From: Vikram KAUL <[email-masked]>
Date: Wed, 14 Sep 2011 12:45:40 -0400 (Eastern Daylight Time)

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 <[email-masked]>
> To: Vikram KAUL <[email-masked]>,
>     "[email-masked]" <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Vikram KAUL
> Sent: Monday, August 15, 2011 8:15 AM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 14 Sep 2011 12:46:55 -0400

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:

> 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 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.
>>
>>

---

From: Joe Macker <[email-masked]>
Date: Wed, 14 Sep 2011 14:58:36 -0400

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
> 
>> 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
>>

---

From: "A. Riley Eller" <[email-masked]>
Date: Thu, 15 Sep 2011 14:08:40 -0700

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.

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 19 Sep 2011 11:19:32 -0400

My apologies for the quick comments on this to date.

In response to Vikram's initial email, I look at a multicast MAC as  
another "destination" in the network. A destination that needs to be  
characterized from a metrics standpoint, so MCAST destinations are  
essentially a DLEP "neighbor". Cognizance of the neighbor can come  
from the radio, provided the radio is doing something like PIM  
"snooping", or it can come from the router. Because of that, we were  
going to insert language into the DLEP spec that Neighbor Up/Neighbor  
Down orders can actually come from either of the session peers (either  
the router or the modem device). If/when the modem receives a Neighbor  
Up from the router, it would be incumbent on the modem to provide  
metrics for that "destination".

Regards,
Stan

On Sep 15, 2011, at 5:08 PM, A. Riley Eller wrote:

> 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.
>
> 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,
>>
>>> 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
>>>

---

From: "A. Riley Eller" <[email-masked]>
Date: Mon, 19 Sep 2011 08:31:53 -0700

Sounds like a fine mechanism to me.