Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re: notes DLEP meeting @ IETF88)

[Teco Boot <[e-mail]>]

Op 15 nov. 2013, om 17:37 heeft Stan Ratliff (sratliff) <[e-mail]> het volgende geschreven:

> 
> On Nov 15, 2013, at 7:11 AM, Teco Boot <[e-mail]> wrote:
> 
>> 
>> Op 15 nov. 2013, om 11:33 heeft Taylor, Rick <[e-mail]> het volgende geschreven:
>> 
>>> Okay, just to back it up a bit, and try to get some clarity in the debate.
>>> 
>>> As I understand it, we are all happy with:
>>> 
>>>  Server                                          Client
>>>  ======================================================
>>> 
>>> 1)  TCP Listen()
>>> 
>>> 2*) Peer_Discovery (UDP) ------------Multicast----------->
>>>    + Version
>>> 
>>> 3)  <--------------------------------------- TCP Connect()
>>> 
>>> 4)  <---------------------------------- Peer_Request (TCP)
>>>                                               + Version
>>>                                     + optional extras 1
> 
> As long as all supported metric TLVs are part of "optional extras 1", I'm OK with this. 
> 
>>> 
>>> 5)  Peer_Accept (TCP) ----------------------------------->
>>>    + Status
>>>    + Version
>>>    + optional extras 2
>>> 
>>> *Step 2 may be replaced with a-priori configuration, mDNS, etc...
>>> 
>>> What we are arguing about is who should be the Client, and who should be the Server.
>>> 
>>> So, I am now calling for everyone's answer to the following question:
>>> 
>>> "Should the modem be the Client or the Server in the above diagram, and why?"
>> 
>> Modem should be the server:
>> - modems are servers today, for link metrics, OA&M etc.
>> - modems provide a service, so they act as server
>> - modems are "thumb" devices and can be reach from anywhere in the Internet, if permitted. No need to configure the modem for it, except setting access rights. No need to fire an "ignition packet".
>> - modems can easily handle many TCP sockets, either TCP server or TCP client
>> - TCP server programming is not more difficult than TCP client
> 
> Obviously I disagree. I've seen emails on this thread that speak of "keeping the modem dumb". Making the modem a TCP server is orthogonal to that approach. As to "an ignition packet", I have *no idea* what that means. UDP traffic is going to be required for discovery. It's pretty easy for me to call any UDP packet sent or received "an ignition packet"., so that particular argument seems specious.

The ignition packet is the additional required (unicast) UDP packet when modem is TCP client and TCP server on other node is several hops away.


> 
> There have also been comments about the 1-to-N relationships (router-to-modem, modem-to-router). In reality, there's *always* been an underlying "N-to-N" notion in DLEP. Now, that was before the decision to change to TCP...

OK, we keep the N-to-M where N < M or N = M or N > M.


> 
>> 
>> 
>>> 
>>> I have intentionally left 'optional extras' 1 and 2 undefined as they may be relevant in your answers.
>> 
>> The Ack in the 3-way handshake is missing. After 5, Server thinks the DLEP session is open, but Client is not aware of it yet. This is minor detail, perhaps indeed use as few packets as possible. Also less state.
> 
> No its not. The Peer Accept is the "ACK". Is it "tow-MAY-tow", or "tow-MAH-tow"? (Maybe a bad joke for the non-native English speakers, but I'm leaving it in).

The ACK on Peer_Accept is missing.


> 
>> 
>> 
>>> 
>>> I will give my answers in a separate email.
>>> 
>>> If anyone has a problem with the above diagram, now is your chance to shout!
>> 
>> Yes, TCP server socket must be opened before the Peer_Discovery. 
> 
> Wow. Just. Wow.
> 
>> After connection, Peer_Discovery packets SHOULD continue to be sent, for the following reasons:
> 
> Seems to me that there's an implicit notion at play here. Specifically, it's that "I (irrespective of whether I'm the modem or the router) will keep strobing discovery packets because I might find other appropriate DLEP peers *on this network segment*." Remember, we've already come close to consensus that discovery is a 1-hop operation, using link-local MCAST.  Having multiple radios on the same network segment (Ethernet) is something that Cisco has long advised customers *NOT* to do.

Good recommendation. 
Without DLEP, it works. Better not have DLEP break what is working today.


> Especially when the RF coverage of those multiple radios overlap with respect to the destinations served - for example let's assume that I have routers that have C-band satellite radios, and some line-of-sight radio. I take 9 or 10 of those setups, and I stick them out in the middle of a flat desert plain, at distances of about 5KM. Everyone can see everyone else, so *both* the C-band satellite radios *and* the LOS radios connect. So far, so good. 
> 
> Now, one of the routers emit a multicast packet (one to a multicast MAC). Or a broadcast packet. Which radio serves it?

With 802.1D, STP is mandatory here.
(I second your recommendation here, don't do this!)


> The problem in this case extends to unicast destinations as well. Since the destination MAC in the packet is the far-end router,

Could be. MAC destination address could also be the modem.


> then in theory *both* radios know about it - after all, they've *both* got connectivity to the exact same far-end MAC address (since everyone has the multiple radios). So in that case, do you get two copies of everything?

No.


> Or does some intervening Ethernet switch try to decide?

Yes.


> If the switch is in play, then "Murphy's Law" (the notion that 'If anything CAN go wrong, it WILL go wrong') will be in play, and chances are the switch will make the *wrong* decision (or at least the decision you DIDN'T expect it to make).

STP is somewhat better than Murphy, but I know what you mean.


>  
> 
> If the connectivity of the two radios is completely orthogonal, then this setup works like a champ. But as the connectivity of the two different RF nets starts to converge, the problems mount. Hence, the recommendation to run multiple radios on *different* network segments - either by using VLANS, or sub interfaces, or just different Ethernet ports if you have to. 

Lets recommend separate interfaces for routers with multiple modems attached (like Figure 2 in DLEP).


> 
> As for the "1-to-N" case from the modem perspective (e.g. 1 modem connected to N routers), you don't really have the problem above - the modem knows it will *always* handle the traffic. But there's an entirely different set of issues. Namely, how *do* you report bandwidth? Yeah, I know - we've been saying "that's the radio's problem." But in looking at the deployment scenario, what would you *recommend* as to how that situation be handled? 

Reporting link metrics is not the problem. It is the multi-party control sessions that introduce complexity.


Teco



> 
> Stan 
> 
>> - no relation between UDP and TCP sockets, more lightweight
>> - for modems that support it, other routers may set up DLEP sessions also
>> - better recovery in case of failures, router knows modem is still present (think of heartbeat=zero)
>> - in line with other discovery protocols (CDP, LLDP, Bonjour etc)
> 
>> 
>> 
>> Teco
>> 
>>> 
>>> Cheers,
>>> 
>>> 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, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com
>>> _______________________________________________
>>> manet-dlep-rg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>> 
>> _______________________________________________
>> manet-dlep-rg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg