Subject: [manet-dlep-rg] London meet up?

From: Rick Taylor <[email-masked]>
Date: Mon, 3 Mar 2014 10:52:05 +0000

Hi All,

I'm not sure how many of you have made it to London, but I shall be coming up for the Wednesday am MANET meeting, and wondered if anyone wanted to get together on Tuesday for a quick chat?  Preferably in the bar as I'm, only paying for the 1-day pass.

Cheers,

Rick

---

From: Teco Boot <[email-masked]>
Date: Mon, 3 Mar 2014 12:30:52 +0100

I’ve seen Henning and Stan around.
Because late subscription, I didn’t get a social ticket. So I’m free on Tuesday evening to enjoy London’s nightlife.

Teco 

Op 3 mrt. 2014, om 11:52 heeft Rick Taylor <[email-masked]> het volgende geschreven:

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

---

From: Henning Rogge <[email-masked]>
Date: Mon, 3 Mar 2014 13:31:24 +0000

I have a ticket for the Social Event...

so Tuesday afternoon doesn't sounds that good for me. Maybe we should
meet after the MANET meeting, so we know already if we need to
continue the DLEP-DT?

Henning

On Mon, Mar 3, 2014 at 11:30 AM, Teco Boot <[email-masked]> wrote:
> I've seen Henning and Stan around.
> Because late subscription, I didn't get a social ticket. So I'm free on Tuesday evening to enjoy London's nightlife.
>
> Teco
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 3 Mar 2014 16:14:42 +0000

After the MANET meeting on Wednesday sounds the most sensible, as I imagine we will all have the great TCP/UDP debate to discuss...

Rick
________________________________________
From: Henning Rogge [[email-masked]]
Sent: 03 March 2014 13:31
To: Teco Boot
Cc: Rick Taylor; [email-masked] Group, ([email-masked])
Subject: Re: [manet-dlep-rg] London meet up?

Henning

---

From: Joseph Macker <[email-masked]>
Date: Mon, 3 Mar 2014 12:59:11 -0500

If you hold the DLEP-DT meeting please cc and allow Justin Dean from my
group to attend and take notes for me.  He is there now and cc'd him on
this message as [email-masked].

I unfortunately could not make London due to a need to provide elderly care
this week.

Regards,

-Joe

On Mon, Mar 3, 2014 at 5:52 AM, Rick Taylor
<[email-masked]>wrote:

> Hi All,
>
> I'm not sure how many of you have made it to London, but I shall be coming
> up for the Wednesday am MANET meeting, and wondered if anyone wanted to get
> together on Tuesday for a quick chat?  Preferably in the bar as I'm, only
> paying for the 1-day pass.
>
> Cheers,
>
> Rick
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 3 Mar 2014 18:03:24 +0000

Justin,

You're welcome to attend. I've just given slides to Ulrich for DLEP; to be honest, I'm recommend that we terminate the DT. We'll see if the WG lets me… ;-)

Regards,
Stan

On Mar 3, 2014, at 12:59 PM, Joseph Macker <[email-masked]<mailto:[email-masked]>>
 wrote:

If you hold the DLEP-DT meeting please cc and allow Justin Dean from my group to attend and take notes for me.  He is there now and cc'd him on this message as [email-masked]<mailto:[email-masked]>.

I unfortunately could not make London due to a need to provide elderly care this week.

Regards,

-Joe

On Mon, Mar 3, 2014 at 5:52 AM, Rick Taylor <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Cheers,

Rick

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

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

---

From: Rick Taylor <[email-masked]>
Date: Wed, 5 Mar 2014 17:35:53 +0000

Hi Guys,

Thank you all very much for a very productive meeting this afternoon.  I include a write up of my notes, please correct me if I have missed anything pertinent.

Stan has committed to updating the session initiation description to place the TCP server in the modem, so the initial part of the protocol is:  Modem broadcasts UDP Hello packets containing version, ident and TCP address/port.  Router TCP connects, session initiation occurs via the new TCP connection.

Credit windowing will stay in the document, but will be clearly marked as an optional part of the protocol.  There was some concern raised over the clarity of the current text which will need to be address before last call.

Vendor extensions will be defined using a new Data Item, containing a OUI (or something from an existing registry) and space for a payload.  There will need to be some guidance verbiage to characterise what is a valid vendor extension and what is not. 

There was clarification of what both ends of a DLEP session must do on reciept of an unrecognized signal and data item.  For a data item, the receiver MUST ignore the data item, for a signal the recipient MUST send an error status signal and terminate the TCP connection. 

There will be no facility in DLEP v1 for vendor extended signals.  Any extra signals will require an uplift of the verion of the protocol and require a new draft.

There will be no such thing as a Peer Characteristic Request.  This will prevent abuse and misuse of the DLEP protocol to act as a configuration mechanism.

There was further discussion concerning multiple QoS flows with seperate metrics across a single link.  This was agreed to be pushed out to another draft after DLEP v1, after some analysis that the proposed approach (heirachial data items) will not break existing DLEP v1 implementations.  Stan agreed to double check that the text specified 16bit length values for all TLVs (data and signals).

There was discussion about enumerating error codes, and potential error text.  The status signal MUST include an error code, 0 being success, others to be enumerated after close analysis of the protocol, plus and optional free text field to carry loggable information, capped at 80 bytes, utf8 encoded.

There was discussion of confidence values for metrics, and this was rejected as a core DLEP mechanism, and the suggestion was to use an extension data item TLV instead.

In light of achieveing their goal of listing the outstanding points that needed to be reolved before DLEP can make progress to WG last-call, and actually achieving suitable consensus to resolve the outstanding issues to the satisafaction of one of the authors present, the DT decided to not apply for a continuation of their charter, and to instead announce "Mission Complete"

Cheers,

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Mar 2014 18:19:05 +0000

I just looked it up, we have no data items in the UDP discovery broadcast
at all at the moment.

Henning
On Mar 5, 2014 5:36 PM, "Rick Taylor" <[email-masked]>
wrote:

> Hi Guys,
>
> Thank you all very much for a very productive meeting this afternoon.  I
> include a write up of my notes, please correct me if I have missed anything
> pertinent.
>
> Stan has committed to updating the session initiation description to place
> the TCP server in the modem, so the initial part of the protocol is:  Modem
> broadcasts UDP Hello packets containing version, ident and TCP
> address/port.  Router TCP connects, session initiation occurs via the new
> TCP connection.
>
> Credit windowing will stay in the document, but will be clearly marked as
> an optional part of the protocol.  There was some concern raised over the
> clarity of the current text which will need to be address before last call.
>
> Vendor extensions will be defined using a new Data Item, containing a OUI
> (or something from an existing registry) and space for a payload.  There
> will need to be some guidance verbiage to characterise what is a valid
> vendor extension and what is not.
>
> There was clarification of what both ends of a DLEP session must do on
> reciept of an unrecognized signal and data item.  For a data item, the
> receiver MUST ignore the data item, for a signal the recipient MUST send an
> error status signal and terminate the TCP connection.
>
> There will be no facility in DLEP v1 for vendor extended signals.  Any
> extra signals will require an uplift of the verion of the protocol and
> require a new draft.
>
> There will be no such thing as a Peer Characteristic Request.  This will
> prevent abuse and misuse of the DLEP protocol to act as a configuration
> mechanism.
>
> There was further discussion concerning multiple QoS flows with seperate
> metrics across a single link.  This was agreed to be pushed out to another
> draft after DLEP v1, after some analysis that the proposed approach
> (heirachial data items) will not break existing DLEP v1 implementations.
>  Stan agreed to double check that the text specified 16bit length values
> for all TLVs (data and signals).
>
> There was discussion about enumerating error codes, and potential error
> text.  The status signal MUST include an error code, 0 being success,
> others to be enumerated after close analysis of the protocol, plus and
> optional free text field to carry loggable information, capped at 80 bytes,
> utf8 encoded.
>
> There was discussion of confidence values for metrics, and this was
> rejected as a core DLEP mechanism, and the suggestion was to use an
> extension data item TLV instead.
>
> In light of achieveing their goal of listing the outstanding points that
> needed to be reolved before DLEP can make progress to WG last-call, and
> actually achieving suitable consensus to resolve the outstanding issues to
> the satisafaction of one of the authors present, the DT decided to not
> apply for a continuation of their charter, and to instead announce "Mission
> Complete"
>
> Cheers,
>
> Rick Taylor
>
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 5 Mar 2014 19:49:38 +0000

Henning,

That's true. The data items would be in the "Peer Offer" response to the Multicasted Discovery. Those data items (IP address and Port) will have to move to the discovery message. Also, any a-priori configuration will need to be implemented in the router instead of the modem, but that's really an "implementation detail".

Regards,
Stan
On Mar 5, 2014, at 1:19 PM, Henning Rogge <[email-masked]<mailto:[email-masked]>>
 wrote:

I just looked it up, we have no data items in the UDP discovery broadcast at all at the moment.

Henning

On Mar 5, 2014 5:36 PM, "Rick Taylor" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Guys,

Cheers,

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Mar 2014 20:21:44 +0000

I wonder if we could allow a MAC address data TLV in the multicast
discovery peer offer.

It would solve a lot of headaches with DLEP Wifi radios in Adhoc mode.

Henning

On Wed, Mar 5, 2014 at 7:49 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> Henning,
>
> That's true. The data items would be in the "Peer Offer" response to the
> Multicasted Discovery. Those data items (IP address and Port) will have to
> move to the discovery message. Also, any a-priori configuration will need to
> be implemented in the router instead of the modem, but that's really an
> "implementation detail".
>
> Regards,
> Stan
> On Mar 5, 2014, at 1:19 PM, Henning Rogge <[email-masked]>
>  wrote:
>
>> broadcasts UDP Hello packets containing version, ident and TCP address/port.
>> Router TCP connects, session initiation occurs via the new TCP connection.
>>
>> Stan agreed to double check that the text specified 16bit length values for
>> all TLVs (data and signals).
>>
>> text.  The status signal MUST include an error code, 0 being success, others
>> to be enumerated after close analysis of the protocol, plus and optional
>> free text field to carry loggable information, capped at 80 bytes, utf8
>> encoded.
>>
>> the satisafaction of one of the authors present, the DT decided to not apply
>> for a continuation of their charter, and to instead announce "Mission
>> Complete"
>>
>> Cheers,
>>
>> Rick Taylor
>>
>>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 5 Mar 2014 20:59:20 +0000

What would that MAC address be used for? I don't understand.

Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Mar 2014 21:02:26 +0000

One option to allow DLEP with adhoc wifi might be to configure the
local MAC address of the routers interface towards the DLEP radio with
the same mac address as the local radio.

This way you can send them over the wifi link without having to do a
nasty MAC-NAT style thing.

It would be a help to be able to reconfigure the MAC on the router
BEFORE I have to open the TCP session.

It might work reconfiguring it afterwards (will trigger new ARP/ICMPv6
requests I think).

Henning

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 5 Mar 2014 21:11:02 +0000

OK, this is IMO, but…

That is pretty much a one-off, for a research or lab-type effort. As a professor of mine in college used to say, "No one in their right mind will ever use 802.11 adhoc for anything more than a development/research platform". I just don't see bending the protocol to put this in for no more use than we'll get out of it. 

After all, nothing stops you from inserting an extra TLV into your own implementation.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Mar 2014 21:14:22 +0000

On Wed, Mar 5, 2014 at 9:11 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> OK, this is IMO, but...

I think MOST wifi based MANETs use adhoc mode, so this is not a
special research/lab usecase.

Thats the default use case for a MANET.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 5 Mar 2014 21:25:15 +0000

Not from what I've seen…. not in industry. Or in military developments. 

Oh, another issue - if I understood you correctly, the MAC that you propose putting into the discovery packet would then be "assumed" by the receiving router? If that's right, wouldn't DLEP become something of a "DHCP for MAC addresses"? This looks really, really wrong to me. 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 5 Mar 2014 21:27:58 +0000

I am just not sure I can change a MAC address of an interface without
breaking a running TCP session on it.

Henning

On Wed, Mar 5, 2014 at 9:25 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> Not from what I've seen.... not in industry. Or in military developments.
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 5 Mar 2014 21:32:25 +0000

> breaking a running TCP session on it.

That's an interesting question. Since you've got a setup already in mind, can I ask you to try it? With the notion of layer independence, it just might work. I know you can't change an IP address on a running TCP session, but I could actually see no one caring about the MAC address(es).

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 5 Mar 2014 22:12:59 +0000

I was just downstairs, smoking a cigarette, when I remembered one of the basic scenarios that stops people from using 802.11 adhoc for really mobile deployments. Thought I'd offer it up as some rationale for my earlier statement regarding 802.11 adhoc. I wish I had the lightening recall and scathing keyboard abilities of some in the MANET working group, but alas, the years, the beer, the medical conditions, and the prescription drugs that go with the medical conditions have slowed the memory access somewhat… ;-) 

I've heard this referred to as the "Split-BSSID Problem", but I don't know if that's the official term, so let me lay out the scenario. While I don't put interval times in my scenario, there on the order of a small number of seconds. That being said, the scenario goes like this: 

1) I configure up 4 802.11 adhoc radios and associated gear for a demo. I configure the radios with 802.11 BSSID "Foo". The gear and the software is works great; everyone can talk to everyone else, it looks beautiful. Now, all I need to do is to get some people for the demo, which uses the radios in a man-packable fashion. Oh, by the way, the demo is at some remote location (let's say Honolulu, because I've always liked the beach). So, I power down the gear, pack it up, and…

2) I get Henning, Teco, Rick, and Stan (after all, I'm going to Honolulu) to do the demo. Once we're down around Waikiki Beach, I hand out the gear (it's still powered off, BTW). 

3) With the gear powered off, Henning and Teco walk to the right; Rick and Stan walk to the left (non-smokers in one direction, smokers in the other). They stroll along the beach, until they get quite a distance from each other (out of 802.11 radio range). 

4) Since it's still early, Henning and Teco, as well as Rick and Stan, get a coffee at the Starbucks (there's one on every corner), and Rick and Stan light up a cigarette (nasty habit). At the appointed time for the demo, 

5) Stan turns his radio and gear on. So does Teco. Stan's radio BEACONs with "Foo" as the BSSID. So does Teco's radio. They don't find anyone. Both radios think "Well, I'm the first guy here". So Stan's radio adds a "magic number", which is really a hash of its MAC address, to the BEACON. Teco's radio computes a different magic number (since he has a different MAC), and does the same thing. A second or two later, 

6) Rick turns his radio on. So does Henning. Rick's radio BEACONs, but sees Stan's radio BEACON as well. So Rick's radio basically says "Oh, cool. There's someone here. I'll just take his magic number, and join the BSSID". So Stan's radio and Rick's radio are chatting away. Henning's radio BEACONs as well, and sees Teco's radio. Henning's radio also says "Cool! Someone's already here", and adopts Teco's magic number. Henning's radio and Teco's radio are also chatting away with each other. 

7) Now, the "mobility scenario" starts. Rick and Stan start walking back down the beach, toward the starting point. Henning and Teco do the same. Before long, all 4 come into radio range with each other. But since they've got different "magic numbers", they *WILL NOT* establish one big, happy, 4-person BSSID. Stan's radio can't talk to either Henning or Teco; neither can Rick's. The demo is starting to go spectacularly wrong…

The only way out of this to power off two of the radios - well, the *right* two radios (either Stan's and Rick's; OR Teco's and Henning's), and power them back up. Then, they'll join the existing adhoc BSSID, and everyone will be happy. The moral of the story? Every radio that participates in an adhoc BSSID MUST be powered up whilst "in range". Otherwise, said radio won't be able to ultimately join the BSSID, even though they're configured correctly. IMO, it's a flaw (and a BIG one) in the adhoc portion of the 802.11 spec.

Thanks for reading and considering my little story… ;-)

Regards,
Stan

---

From: Joe Macker <[email-masked]>
Date: Wed, 5 Mar 2014 17:57:24 -0500

Cool (especially Waikiki), that;s old one but a goodie as they say!
I think non-spec workarounds exist (dependent on the hardward/software driver).

Early on in 802.11 spec there was this idea a coalesce algorithm (like always move towards the highest BSSID you hear in your neighborhood) in early 2000s I remember some systems worked this way (not saying the spec ever said anything about it).  Certainly even when manufacturers did something like this there was a convergence time and this was reported in a few older research papers. 

I don’t think it was ever included because everyone in the committee had different ideas of how to do it? (sound familiar).

—— not a solution to the adhoc formation problem but-----
I think I remember openWRT having both some form of convergence setting (pick older BSSID you hear so allowing for eventual convergence) and some way to override this manually when planning say a community network. Maybe not. I assume Henning would know more given experience that hardware,etc.

Even though it may not be well documented I thought there was an "iwconfig command" for overriding the BSSID and also a convergence algorithm that still works in that deployment hardware if chosen.

I agree not being in the spec has caused people and systems to develop work arounds and the very least makes for inconsistent features.
---------------------------

---

From: Joe Macker <[email-masked]>
Date: Wed, 5 Mar 2014 18:51:55 -0500

Also heard you guys had a productive DLEP meeting!
I apologize for not being there.

-Joe

---

From: Henning Rogge <[email-masked]>
Date: Thu, 6 Mar 2014 07:40:11 +0000

Damned Stan...

I read your long post and decided "I will formulate a great argument
when I got a shower"... and I think I have found a good argument how
to resolve the problem, unfortunately its self-defeating.

I somehow managed to convince me that it might be better to change the
mac address of the wifi card and not the mac address of the routers
interface, because that is more along the line "the router
controls/configures the radio". Consider the request for the "mac" TLV
in the first peer discovery dropped.

About the Adhoc stuff, I think you underestimate the amount of work
the linux community did with their wifi-stack in the last 5 years.
IBSS/Adhoc mode is normally working very well, I have not heard about
huge "split net" problems for quite some time.

Of course most community networks solved this problem even earlier by
just setting a fixed BSSID on all nodes.

Henning Rogge

On Wed, Mar 5, 2014 at 10:57 PM, Joe Macker <[email-masked]> wrote:
> I don't think it was ever included because everyone in the committee had different ideas of how to do it? (sound familiar).
>
> ---- not a solution to the adhoc formation problem but-----
>> I was just downstairs, smoking a cigarette, when I remembered one of the basic scenarios that stops people from using 802.11 adhoc for really mobile deployments. Thought I'd offer it up as some rationale for my earlier statement regarding 802.11 adhoc. I wish I had the lightening recall and scathing keyboard abilities of some in the MANET working group, but alas, the years, the beer, the medical conditions, and the prescription drugs that go with the medical conditions have slowed the memory access somewhat... ;-)
>>
>> 1) I configure up 4 802.11 adhoc radios and associated gear for a demo. I configure the radios with 802.11 BSSID "Foo". The gear and the software is works great; everyone can talk to everyone else, it looks beautiful. Now, all I need to do is to get some people for the demo, which uses the radios in a man-packable fashion. Oh, by the way, the demo is at some remote location (let's say Honolulu, because I've always liked the beach). So, I power down the gear, pack it up, and...
>>
>> 7) Now, the "mobility scenario" starts. Rick and Stan start walking back down the beach, toward the starting point. Henning and Teco do the same. Before long, all 4 come into radio range with each other. But since they've got different "magic numbers", they *WILL NOT* establish one big, happy, 4-person BSSID. Stan's radio can't talk to either Henning or Teco; neither can Rick's. The demo is starting to go spectacularly wrong...
>>
>> Thanks for reading and considering my little story... ;-)
>>
>> Regards,
>> Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:05:14 +0100

You missed cleanup delay and EFT, microseconds, 32-bit. Max is over an hour delay. Space agencies may have their own extension TLVs.

I did in-depth review on pre-05. Most of remarks is still to be incorporated.
I’ll better wait check again until pre-06?

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:18:29 +0100

My opinion on MAC NAT hack or Dup MAC address: nice but ugly. Breaks 802.1D even more. Let’s not standardize it.
Ronald fixed 802.11D for MadWiFi in Ad Hoc, 4-addr mode. Others use encap with another MAC header. Both are much cleaner.

Or I miss something.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 6 Mar 2014 09:23:36 +0000

I dont think there is a current wifi driver with 4 address adhoc mode.

Henning
On Mar 6, 2014 9:18 AM, "Teco Boot" <[email-masked]> wrote:

> My opinion on MAC NAT hack or Dup MAC address: nice but ugly. Breaks
> 802.1D even more. Let's not standardize it.
> Ronald fixed 802.11D for MadWiFi in Ad Hoc, 4-addr mode. Others use encap
> with another MAC header. Both are much cleaner.
>
> Or I miss something.
>
> Teco
>
> >>>> I just looked it up, we have no data items in the UDP discovery
> broadcast at
> >>>> all at the moment.
> >>>>
> >>>> Henning
> >>>>
> >>>> On Mar 5, 2014 5:36 PM, "Rick Taylor" <[email-masked]
> >
> >>>> wrote:
> >>>>>
> >>>>> Hi Guys,
> >>>>>
> address/port.

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:38:34 +0100

So we should throw away our PS radio’s?
Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:39:55 +0100

> Not from what I've seen…. not in industry. Or in military developments. 

You missed a lot.

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:41:09 +0100

> Oh, another issue - if I understood you correctly, the MAC that you propose putting into the discovery packet would then be "assumed" by the receiving router? If that's right, wouldn't DLEP become…

(Again)

+1

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:48:10 +0100

> breaking a running TCP session on it.

So don’t change if no reason for it.

In the 802.1D network, each NIC should have an unique MAC address and should be reachable. If not, we are near to disaster.
Dynamic MAC addresses for privacy is something that happens already. Good implementations don’t break connections. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 10:58:51 +0100

Stan, we know about the buggy BSSID coalescing. Bugs are solved in most drivers. Other drivers simply disable IBBS (ad hoc) mode. 
In most WLAN ad hoc networks, BSSID is generated as pseudo-random on SSID and optionally the channel ID. Or configured manually. Also, many WLAN ad hoc implementations deviate a little bit from the 802.11 standard by disabling management frames at all. The military WLAN based radio’s deviate a little bit more than the community networks, by adjusted drivers, firmware and RF circuits.

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Thu, 6 Mar 2014 10:21:09 +0000

> You missed cleanup delay and EFT, microseconds, 32-bit. Max is over an
> hour delay. Space agencies may have their own extension TLVs.

Thanks Teco, I'll add it to the list of achievements.

> I'll better wait check again until pre-06?

Yes, I think it's only fair of us to let Stan find some cycles to update the 05 draft, and prompt him again if he has missed anything we feel important.

Anyone else have any updates, or shall I post an updated version to the WG list? (there were some typos as well)

Rick
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, part of the Airbus Defence and Space division. Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ. Registered in England and Wales under company number 04191036

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Mar 2014 11:24:47 +0100

Because there 802.11s, this provides enough space for addresses.

The tunnel approach has less impact on the driver, so would be more easy to implement.
For full 802.1D, there is a need for a bridge table, with DestAddr to RecvAddr mapping.

BTW, for Stan: The large organization I work for uses Cisco AP’s because they can mesh…. Not 11s, not IBSS, but functional equivalent. 

Teco

---

From: John Dowdell <[email-masked]>
Date: Thu, 6 Mar 2014 18:30:49 +0000

All

I am going to show my ignorance here, but is this 'feature' fixed in
802.11s do you know?

Regards
John

On Thursday, March 6, 2014, Teco Boot <[email-masked]> wrote:

> Stan, we know about the buggy BSSID coalescing. Bugs are solved in most
> drivers. Other drivers simply disable IBBS (ad hoc) mode.
> In most WLAN ad hoc networks, BSSID is generated as pseudo-random on SSID
> and optionally the channel ID. Or configured manually. Also, many WLAN ad
> hoc implementations deviate a little bit from the 802.11 standard by
> disabling management frames at all. The military WLAN based radio's deviate
> a little bit more than the community networks, by adjusted drivers,
> firmware and RF circuits.
>
> Teco
>
> Op 5 mrt. 2014, om 23:12 heeft Stan Ratliff (sratliff) <[email-masked]<javascript:;>>
> het volgende geschreven:
>
> > I was just downstairs, smoking a cigarette, when I remembered one of the
> basic scenarios that stops people from using 802.11 adhoc for really mobile
> deployments. Thought I'd offer it up as some rationale for my earlier
> statement regarding 802.11 adhoc. I wish I had the lightening recall and
> scathing keyboard abilities of some in the MANET working group, but alas,
> the years, the beer, the medical conditions, and the prescription drugs
> that go with the medical conditions have slowed the memory access somewhat...
> ;-)
> >
> > I've heard this referred to as the "Split-BSSID Problem", but I don't
> know if that's the official term, so let me lay out the scenario. While I
> don't put interval times in my scenario, there on the order of a small
> number of seconds. That being said, the scenario goes like this:
> >
> > 1) I configure up 4 802.11 adhoc radios and associated gear for a demo.
> I configure the radios with 802.11 BSSID "Foo". The gear and the software
> is works great; everyone can talk to everyone else, it looks beautiful.
> Now, all I need to do is to get some people for the demo, which uses the
> radios in a man-packable fashion. Oh, by the way, the demo is at some
> remote location (let's say Honolulu, because I've always liked the beach).
> So, I power down the gear, pack it up, and...
> >
> > 2) I get Henning, Teco, Rick, and Stan (after all, I'm going to
> Honolulu) to do the demo. Once we're down around Waikiki Beach, I hand out
> the gear (it's still powered off, BTW).
> >
> > 3) With the gear powered off, Henning and Teco walk to the right; Rick
> and Stan walk to the left (non-smokers in one direction, smokers in the
> other). They stroll along the beach, until they get quite a distance from
> each other (out of 802.11 radio range).
> >
> > 4) Since it's still early, Henning and Teco, as well as Rick and Stan,
> get a coffee at the Starbucks (there's one on every corner), and Rick and
> Stan light up a cigarette (nasty habit). At the appointed time for the demo,
> >
> > 5) Stan turns his radio and gear on. So does Teco. Stan's radio BEACONs
> with "Foo" as the BSSID. So does Teco's radio. They don't find anyone. Both
> radios think "Well, I'm the first guy here". So Stan's radio adds a "magic
> number", which is really a hash of its MAC address, to the BEACON. Teco's
> radio computes a different magic number (since he has a different MAC), and
> does the same thing. A second or two later,
> >
> > 6) Rick turns his radio on. So does Henning. Rick's radio BEACONs, but
> sees Stan's radio BEACON as well. So Rick's radio basically says "Oh, cool.
> There's someone here. I'll just take his magic number, and join the BSSID".
> So Stan's radio and Rick's radio are chatting away. Henning's radio BEACONs
> as well, and sees Teco's radio. Henning's radio also says "Cool! Someone's
> already here", and adopts Teco's magic number. Henning's radio and Teco's
> radio are also chatting away with each other.
> >
> > 7) Now, the "mobility scenario" starts. Rick and Stan start walking back
> down the beach, toward the starting point. Henning and Teco do the same.
> Before long, all 4 come into radio range with each other. But since they've
> got different "magic numbers", they *WILL NOT* establish one big, happy,
> 4-person BSSID. Stan's radio can't talk to either Henning or Teco; neither
> can Rick's. The demo is starting to go spectacularly wrong...
> >
> > The only way out of this to power off two of the radios - well, the
> *right* two radios (either Stan's and Rick's; OR Teco's and Henning's), and
> power them back up. Then, they'll join the existing adhoc BSSID, and
> everyone will be happy. The moral of the story? Every radio that
> participates in an adhoc BSSID MUST be powered up whilst "in range".
> Otherwise, said radio won't be able to ultimately join the BSSID, even
> though they're configured correctly. IMO, it's a flaw (and a BIG one) in
> the adhoc portion of the 802.11 spec.
> >
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 6 Mar 2014 18:33:00 +0000

Not sure I want to pretend 802.11s fixed anything...

Henning
On Mar 6, 2014 6:30 PM, "John Dowdell" <[email-masked]> wrote:

>> Op 5 mrt. 2014, om 23:12 heeft Stan Ratliff (sratliff) <
>> [email-masked]> het volgende geschreven:
>>
>> > I was just downstairs, smoking a cigarette, when I remembered one of
>> the basic scenarios that stops people from using 802.11 adhoc for really
>> mobile deployments. Thought I'd offer it up as some rationale for my
>> earlier statement regarding 802.11 adhoc. I wish I had the lightening
>> recall and scathing keyboard abilities of some in the MANET working group,
>> but alas, the years, the beer, the medical conditions, and the prescription
>> drugs that go with the medical conditions have slowed the memory access
>> somewhat... ;-)
>> >
>> > 7) Now, the "mobility scenario" starts. Rick and Stan start walking
>> back down the beach, toward the starting point. Henning and Teco do the
>> same. Before long, all 4 come into radio range with each other. But since
>> they've got different "magic numbers", they *WILL NOT* establish one big,
>> happy, 4-person BSSID. Stan's radio can't talk to either Henning or Teco;
>> neither can Rick's. The demo is starting to go spectacularly wrong...
>> >

---

From: Joe Macker <[email-masked]>
Date: Thu, 6 Mar 2014 17:43:37 -0500

We did the same in early experiments  many moons ago by fixing BSSID.
As I was mentioning I think iwconfig supports that directly.

-Joe

---

From: Teco Boot <[email-masked]>
Date: Fri, 7 Mar 2014 01:09:45 +0100

The spec was never broken. Drivers were buggy.

.11s has a nice airtime metric :-)

Teco

Op 6 mrt. 2014, om 19:33 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> I am going to show my ignorance here, but is this 'feature' fixed in 802.11s do you know?
> 
> Regards
> John
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 7 Mar 2014 07:25:29 +0000

And "iwconfig" has been  deprecated for a number of years and have been
replaced by the much more powerful/versatile "iw" command.

Henning
On Mar 6, 2014 10:43 PM, "Joe Macker" <[email-masked]> wrote:

> >> Early on in 802.11 spec there was this idea a coalesce algorithm (like
> always move towards the highest BSSID you hear in your neighborhood) in
> early 2000s I remember some systems worked this way (not saying the spec
> ever said anything about it).  Certainly even when manufacturers did
> something like this there was a convergence time and this was reported in a
> few older research papers.
> >>
> >> I don't think it was ever included because everyone in the committee
> had different ideas of how to do it? (sound familiar).
> >>
> >> I think I remember openWRT having both some form of convergence setting
> (pick older BSSID you hear so allowing for eventual convergence) and some
> way to override this manually when planning say a community network. Maybe
> not. I assume Henning would know more given experience that hardware,etc.
> >>
> >> Even though it may not be well documented I thought there was an
> "iwconfig command" for overriding the BSSID and also a convergence
> algorithm that still works in that deployment hardware if chosen.
> >>
> >> I agree not being in the spec has caused people and systems to develop
> work arounds and the very least makes for inconsistent features.
> >>> 1) I configure up 4 802.11 adhoc radios and associated gear for a
> demo. I configure the radios with 802.11 BSSID "Foo". The gear and the
> software is works great; everyone can talk to everyone else, it looks
> beautiful. Now, all I need to do is to get some people for the demo, which
> uses the radios in a man-packable fashion. Oh, by the way, the demo is at
> some remote location (let's say Honolulu, because I've always liked the
> beach). So, I power down the gear, pack it up, and...
> >>>
> >>> 5) Stan turns his radio and gear on. So does Teco. Stan's radio
> BEACONs with "Foo" as the BSSID. So does Teco's radio. They don't find
> anyone. Both radios think "Well, I'm the first guy here". So Stan's radio
> adds a "magic number", which is really a hash of its MAC address, to the
> BEACON. Teco's radio computes a different magic number (since he has a
> different MAC), and does the same thing. A second or two later,
> >>>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 7 Mar 2014 16:32:44 +0000

Ok, I want to get back to the notion that started all of this - namely, the idea of letting the radio put a MAC address into the discovery packet. As I understand it, this MAC address would be picked up and used by the router as it's new MAC address on the interface. I've got multiple reasons why I'm opposed:

1. There's no guarantee the supplied MAC address would be unique. 
2. This is a layer violation. 
3. I don't see how this would work in the case where multiple radios are attached to 1 router via the same interface. There are lots of other reasons not to attach multiple radios *to the same router interface*, the primary one being how broadcast packets get handled. Seems like this would make it tons and tons worse, if the router is re-addressing (at layer 2) its interface based on "the last radio to issue discovery". 

But maybe then, I don't understand the rationale behind the change. 

Having said all that, I had a bit of an "A-ha!" moment on the plane ride home. I submit this is a *perfect* example for the use of experimental Data Item TLVs. Henning can put the MAC address on an experimental TLV in discovery. His implementation on the router side would understand it, and process it as he likes. Other implementations (like mine, for instance) would, by our definition in London, parse and silently drop the experimental TLV. And Eureka! Henning's implementation works as he wants, whilst interoperability is preserved. 

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 7 Mar 2014 16:33:55 +0000

> Ronald fixed 802.11D for MadWiFi in Ad Hoc, 4-addr mode. Others use encap with another MAC header. Both are much cleaner.

I'm in agreement with Teco. See my earlier (and admittedly out-of-sequence) reply on the list. 

Regards,
Stan

> Teco
[snip]

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 7 Mar 2014 16:39:31 +0000

> So we should throw away our PS radio’s?

No. The PS radios use 802.11 *spectrum* (2.4GHz), but do NOT use 802.11 layer 2. They wrote their own. I think they borrowed the frame formats, but nothing more. So comparing Persistent Systems to a WiFi radio is apples-to-oranges. 

Regards,
Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 10 Mar 2014 10:13:56 +0000

<SNIP>

> Having said all that, I had a bit of an "A-ha!" moment on the plane ride home.
> I submit this is a *perfect* example for the use of experimental Data Item
> TLVs. Henning can put the MAC address on an experimental TLV in discovery.
> His implementation on the router side would understand it, and process it as
> he likes. Other implementations (like mine, for instance) would, by our
> definition in London, parse and silently drop the experimental TLV. And
> Eureka! Henning's implementation works as he wants, whilst interoperability
> is preserved.
>

Absolutely!

That's exactly how I imagined either experimental or vendor extensions to work.  In this case, the question for Henning is whether he wants to implement this using a Data Item in the experimental space until he has a chance to add it to his draft 802.11-DLEP-extensions draft, or use a vendor extension TLV, using his own OUI, documenting and circulating it privately.

Cheers,

Rick

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 10 Mar 2014 10:27:01 +0000

Hi All,

Here is my updated list of TODOs that became DONEs (I reckon we should get the output of our meeting on the main WG list while there is still lots of post meeting activity)

Stan has committed to updating the session initiation description to place the
TCP server in the modem, so the initial part of the protocol is:  Modem
broadcasts UDP Hello packets containing version, ident and TCP
address/port.  Router TCP connects, session initiation occurs via the new TCP
connection.

Credit windowing will stay in the document, but will be clearly marked as an
optional part of the protocol.  There was some concern raised over the clarity
of the current text which will need to be address before last call.

Vendor extensions will be defined using a new Data Item, containing a OUI
(or something from an existing registry) and space for a payload.  There will
need to be some guidance verbiage to characterise what is a valid vendor
extension and what is not.

There was clarification of what both ends of a DLEP session must do on
receipt of an unrecognized signal and data item.  For a data item, the receiver
MUST ignore the data item, for a signal the recipient MUST send an error
status signal and terminate the TCP connection.

There will be no facility in DLEP v1 for vendor extended signals.  Any extra
signals will require an uplift of the verion of the protocol and require a new
draft.

There will be no such thing as a Peer Characteristic Request.  This will prevent
abuse and misuse of the DLEP protocol to act as a configuration mechanism.

The latency and EFT metrics were agreed to be fundamentally the same metric,
whether EFT is used to measure the latency or some other algorithm, and so EFT
will be dropped from the draft, leaving latency, with some text covering the use
of EFT for defining latency.  Also, it was decided that latency should be defined as a
32-bit positive number of microseconds.

There was further discussion concerning multiple QoS flows with seperate
metrics across a single link.  This was agreed to be pushed out to another
draft after DLEP v1, after some analysis that the proposed approach
(hierarchical data items) will not break existing DLEP v1 implementations.  Stan
agreed to double check that the text specified 16bit length values for all TLVs
(data and signals).

There was discussion about enumerating error codes, and potential error
text.  The status signal MUST include an error code, 0 being success, others to
be enumerated after close analysis of the protocol, plus and optional free
text field to carry loggable information, capped at 80 bytes, utf8 encoded.

There was discussion of confidence values for metrics, and this was rejected
as a core DLEP mechanism, and the suggestion was to use an extension data
item TLV instead.

In light of achieving their goal of listing the outstanding points that needed
to be resolved before DLEP can make progress to WG last-call, and actually
achieving suitable consensus to resolve the outstanding issues to the
satisfaction of one of the authors present, the DT decided to not apply for a
continuation of their charter, and to instead announce "Mission Complete"

Rick

---

From: Teco Boot <[email-masked]>
Date: Mon, 10 Mar 2014 07:54:14 +0100

> No. The PS radios use 802.11 *spectrum* (2.4GHz), but do NOT use 802.11 layer 2. They wrote their own. I think they borrowed the frame formats, but nothing more. So comparing Persistent Systems to…

WiFi != 802.11.

Many ad hoc radio’s are based on 802.11 IBSS. They do deviate. An important deviation: For LAN connected nodes, we need at least four MAC address fields, not three as in IBSS.

The 802.11 MBSS (Mesh BSS, 11s) header supports the number of MAC addresses we need.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 10 Mar 2014 15:17:43 +0000

On Mar 10, 2014, at 2:54 AM, Teco Boot <[email-masked]>
 wrote:

> Many ad hoc radio’s are based on 802.11 IBSS. They do deviate.

Fine. Then I'm not sure what we're arguing about. I initially said "No one in their right mind will ever use 802.11 adhoc for anything more than a development/research platform." You're basically telling me "Yeah, you can if you hack the crap out of it." Got it. If you change enough software, you can make anything happen. I'll stand by my original statement. I guess that means you and I won't ever be working on an 802.11 adhoc deployment together… So let's lay that issue aside, and focus on places where we can potentially make headway.

I'm *still* opposed to codifying a deviation, or set of deviations, into the DLEP spec. As was mentioned in another email, this is an opportunity to use experimental Data Item TLVs. I believe use of the experimental (or even the Vendor extension, as Rick mentioned in another email) will take care of this issue.

Stan

> An important deviation: For LAN connected nodes, we need at least four MAC address fields, not three as in IBSS.
>