Subject: Re: [manet-dlep-rg] Meeting time and date

From: "Dowdell, John" <[email-masked]>
Date: Fri, 1 Nov 2013 12:10:52 +0000

All

The meeting will be at 0930 until 1130 PST Tuesday 5 November in the Mosaic bar, unless we can find a more suitable venue.

Henning and Bow-Nan will participate remotely via Google Hangout as it supports group video calling for free. Teco would you arrange the necessary technology please?

Agenda philosophy: The idea of members collecting actions to execute a specific task seemed to work well at Berlin, so I would propose that we aim to finish this meeting with members taking actions to execute time-bounded tasks and report at the London meeting in March 2014. Please therefore come to the meeting with thoughts on what you feel are the next small steps you would like to make in the development of the protocol.

May I be so bold as to suggest two strands of future development:
- Engineering: standardisation of number representation, message formats, etc to form a common baseline for implementors
- Science: the ongoing research on how best to represent the radio environment to a locally attached router and other interested functions. I suggest
        - bandwidth (especially across multi-hop mesh networks)
        - time (air interface latency, queueing delay, forwarding delay)
        - multiple flows (queueing discipline, flow labelling)
        - credit windowing, congestion control

Agenda as follows

- Bash the agenda
- Welcome new members since Berlin
- Current status of DLEP draft
- Actions from Berlin
- Review of papers on radio metrics post Berlin meeting: as we go, discussion on implications for DLEP metrics
- Proposals for work items in next period to London meeting

Regards
John

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Teco Boot <[email-masked]>
Date: Fri, 1 Nov 2013 14:47:03 +0100

I prepared Hangouts. Tested with Henning. Worked well.

Teco

Op 1 nov. 2013, om 13:10 heeft Dowdell, John <[email-masked]> het volgende geschreven:

> _______________________________________________
> manet-dlep-rg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 1 Nov 2013 14:17:00 +0000

Hmmm, Google hangout……. the NSA will be happy with us.. ;-)

Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 1 Nov 2013 18:06:30 +0100

So do you trust Microsoft (Skype owner) more than Google? ;)

Henning

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 1 Nov 2013 17:16:04 +0000

The short answer? "No"… ;-) 

Regards,
Stan

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 4 Nov 2013 15:13:21 -0500

Hi guys,

Thanks for setting this up. I'm wondering if there will be time to discuss
questions/concerns for the actual protocol we have. Martin will bring a
list to socialize, but here's some initial thoughts:

1. Protocol Issues - making sure that things are actually interoperable
(shoulds vs. musts)

2. Multicast - how R2RI would work with multicast or what you guys
envision for it. Is it a separate neighbor for each mcast group? Does the
router initiate or the radio? How metrics would work for this

3. Multi-hop mesh radios - we've had tons of discussions on this before..

4. Flow control and multiple radio and router queues

The goal isn't to solve these problems, but to bring up some operating
constraints and how DLEP might be able to accommodate these issues. In
some cases, we might just say "DLEP does not work here.. You need
something else" and that's fine.

Lemme know..

-Bow-Nan

--
Bow-Nan Cheng, Ph.D.
MIT Lincoln Laboratory
Airborne Networks Group
244 Wood St Lexington MA 02420
781-981-4997

On 11/1/13 1:16 PM, "Stan Ratliff (sratliff)" <[email-masked]> wrote:

>The short answer? "No"Š ;-)
>
>Regards,
>Stan
>
>>> Hmmm, Google hangoutŠŠ. the NSA will be happy with us.. ;-)
>>> 
>>> Stan
>>> 
>>>> Op 1 nov. 2013, om 13:10 heeft Dowdell, John
>>>><[email-masked]> het volgende geschreven:
>>>> 
>>>>> All
>>>>> 
>>>>> The meeting will be at 0930 until 1130 PST Tuesday 5 November in the
>>>>>Mosaic bar, unless we can find a more suitable venue.
>>>>> 
>>>>> Henning and Bow-Nan will participate remotely via Google Hangout as
>>>>>it supports group video calling for free. Teco would you arrange the
>>>>>necessary technology please?
>>>>> 
>>>>> Agenda philosophy: The idea of members collecting actions to execute
>>>>>a specific task seemed to work well at Berlin, so I would propose
>>>>>that we aim to finish this meeting with members taking actions to
>>>>>execute time-bounded tasks and report at the London meeting in March
>>>>>2014. Please therefore come to the meeting with thoughts on what you
>>>>>feel are the next small steps you would like to make in the
>>>>>development of the protocol.
>>>>> 
>>>>> - Engineering: standardisation of number representation, message
>>>>>formats, etc to form a common baseline for implementors
>>>>> - Science: the ongoing research on how best to represent the radio
>>>>>environment to a locally attached router and other interested
>>>>>functions. I suggest
>>>>> - Review of papers on radio metrics post Berlin meeting: as we go,
>>>>>discussion on implications for DLEP metrics
>>>>> The information contained within this e-mail and any files attached
>>>>>to this e-mail is private and in addition may include commercially
>>>>>sensitive information. The contents of this e-mail are for the
>>>>>intended recipient only and therefore if you wish to disclose the
>>>>>information contained within this e-mail or attached files, please
>>>>>contact the sender prior to any such disclosure. If you are not the
>>>>>intended recipient, any disclosure, copying or distribution is
>>>>>prohibited. Please also contact the sender and inform them of the
>>>>>error and delete the e-mail, including any attached files from your
>>>>>system. Cassidian Limited, Registered Office : Quadrant House, Celtic
>>>>>Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
>>>>>http://www.cassidian.com

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 4 Nov 2013 17:34:45 -0500

A little more detail:

1. Protocol Issues
	a. SHOULD vs. MUST - DLEP Version, MDRR/MDRT/CDRT/CDRR
	b. Status TLV is vague
	c. Heartbeat Interval Issues
 
2. Multihop radios
	a. Need for router to distinguish
	b. Single-hop vs. multihop traffic delivery
	c. Topology Management
 
3. Multicast
	a. What is the spec trying to describe?
	b. Peer Discovery nukes existing sessions
	c. 0xff:ff:ff:ff:ff:ff collides with local traffic?
	d. Use of multicast IP addresses
	e. Single-hop/multi-hop implications
 
4. Flow Control 
	a. Per neighbor vs. per peer
	b. Multiple queues to avoid head-of-line blocking
 
5. Metrics
	a. Current metrics: EFT/Latency, Resources, RLQ
	b. Hop Count/Potential Neighbor
	c. Topo Mgmt
	d. Higher latency resolution

-Bow-Nan

On 11/4/13 3:13 PM, "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
wrote:

>>The short answer? "No"? ;-)
>>
>>Regards,
>>Stan
>>
>>>> Hmmm, Google hangout??. the NSA will be happy with us.. ;-)
>>>> 
>>>> Stan
>>>>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 6 Nov 2013 07:10:36 +0000

Gentlemen, 

I had a thought (which usually gets me into a lot of trouble)… 

When we chatted today about DLEP support for Multicast, I was explaining that what DLEP currently terms a "Neighbor" is "a destination in the RF network". That "destination" could be a physical device (as in the case of a unicast MAC/IP address), or a logical destination (as in a Multicast MAC/IP). 

So, my thought/question - would it be helpful at all to change the DLEP terminology to refer to "Destinations" as opposed to "Neighbors"? In other words, we would have a "Destination Up" order, "Destination Down" and "Destination Status"… if it helps to make the spec clearer, then great. If not, I'm happy to leave things well enough alone. 

Thoughts? 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 6 Nov 2013 09:30:35 +0100

I support this change...

in fact I did it too for my rogge-stateless-rfc5444-dlep draft because
of the mixup between neighbors and multicast.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 6 Nov 2013 07:40:01 -0800

+1

With this change, the DLEP Destination will correspond with the Ethernet Destination Address in user traffic.

I have to go over my notes on addresses. I want to make sure there is no expected dependency on whatever configuration at remote node. Could be modem only, could be modem with multiple connected devices. As an example, I have an WiFi access point in mind, isolated or connected to an Ethernet with several routers and hosts.

For this multiple routers and hosts example, we have two options.
1) each and every address on the AP connected ethernet is a Destination. Link metrics would be equal for each of the Destinations but are handled by separate messages.
2) Select a single Destination. Would be an AP MAC address. Then add additional addresses, which could be IPv4 address, IPv6 addresses and MAC addresses. The IPv4 and IPv6 addresses may have associated MAC address (I believe some want to circumvent delays caused by ARP/NDP).

I think option 2 is the cleanest. Details on the additional MAC addresses have to be worked out.

By the way, the WiFi access point example is already in the draft. I suggest to keep it and use it how DLEP works. It is a nice example of a two L2 hop network where things get complicated. I’m not saying I am a fan of WiFi nor the access point mode of operation.  

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 6 Nov 2013 17:05:31 +0100

> I have to go over my notes on addresses. I want to make sure there is no expected dependency on whatever configuration at remote node. Could be modem only, could be modem with multiple connected de…

You mean connecting the DLEP capable radio to a switch/bridge and then
to multiple ethernet devices without a DLEP-router in between?

Henning Rogge

---

From: Joe Macker <[email-masked]>
Date: Wed, 6 Nov 2013 09:25:45 -0800

Destination to me seems to work better for multicast but now on the other coin side destination terminology might be confusing for unicast since its only an interface peer or local destination from the routing point of view. Just a thought also uh oh. am i in trouble as well?

---

From: Henning Rogge <[email-masked]>
Date: Wed, 6 Nov 2013 19:48:55 +0100

@Joe Macker:

Is it?

In fact every destination (or neighbor) is a mac address you can use
as a "destination address" in the ethernet frame to communicate over
the radio. Works both for unicast and multicast/broadcast.

Henning Rogge

---

From: Joe Macker <[email-masked]>
Date: Wed, 6 Nov 2013 11:27:28 -0800

See I got in trouble as I said I would ;-).

Of course all things are destinations in the L2 sense. I think I said that albeit "local" destination". Just concerned others might confuse it again as an "over the air", multi-hop protocol without adding text to define the destination term carefully. Again maybe I am too sensitive to this since so many people that talk to me (outside of the DT) misunderstand DLEP functionality. When adding multicast/unicast functionality destination is the better term. So I am in agreement although I had this paranoid nit.

So perhaps a short,explicit terminology section to avoid confusion by carefully defining the scope of terms in DLEP, e.g., what is meant by a DLEP destination in document. I think you actually just provided some of that text.  The upfront short statement to distinguish DLEP applicability as a "logical" local interface association may also avoid this. I was using "logical" because DLEP may not always be physically local.

-joe

---

From: Teco Boot <[email-masked]>
Date: Wed, 6 Nov 2013 13:16:45 -0800

> to multiple ethernet devices without a DLEP-router in between?
Could be.
What I say is that there is absolutely no assumed configuration on remote node. Can have a switch with multiple connected nodes, some of them are routers, some routers or hosts are DLEP capable.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 6 Nov 2013 22:49:48 +0100

I would say you should get all of them...

Yes, its not efficient, but thats the penalty you get when you connect
a bridged radio directly to an ethernet switch.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 7 Nov 2013 19:28:01 -0800

I do not want to exclude any opportunity. Recently I had a satcom modem in hand with multiple ethernet interfaces. Modem acts as bridge. Perfect candidate for DLEP.

Why is this inefficient?

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 8 Nov 2013 10:26:53 +0100

Its inefficient for DLEP because it has to deliver each metric
multiple times (because the radio itself has no destination
identifier).

But it should work.

Another way to do this (more efficiently) would be to allow multiple
MAC TLVs for the same neighbor up/down/update message... but that
sounds messy for the implementation.

Henning Rogge