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

[Teco Boot <[e-mail]>]

Op 15 nov. 2013, om 19:29 heeft Stan Ratliff (sratliff) <[e-mail]> het volgende geschreven:
>>> 
>>> 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).
> 
> We're in agreement there. But that recommendation does implicitly offer up a protocol optimization - that being, once you've found a DLEP partner on a given network segment (or interface), you can stop strobing discovery packets *on that segment* (or interface). Not that you have to - after all, it's a recommendation, not a MUST. 

Top be decided after we know who is TCP server.
If modem is TCP server, it should continue sending discovery packets, for newly attached routers to the ethernet segment.
If router is TCP server, it may stop discovery after TCP connection setup.

> 
>> 
>> 
>>> 
>>> 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.
> 
> Well… reporting link metrics *is* a problem. The modem has a finite amount of RF. In this scenario, it has multiple entities trying to access the finite resource. All of those multiple entities (the routers) want to know how big the pipe is. It's not really much different than in the L2 mesh networking case, where there are multiple hops in the L2 mesh.  It becomes really, really easy for the modem to over-commit the RF resource. Multiple control sessions might be a problem as well, especially with the Link Characteristics Request. If router "A" asks for link characteristics that ultimately wind up interfering with router "B", I can see where a conflict can arise. I would expect the modem to mitigate that problem with "some vendor-specific heuristics". Outside of the LCR, the other MAJOR faux-pas I can see with multiple sessions happens *ONLY* when they are on the same local Ethernet segment (e.g. somebody that does NOT take our recommendation). Credits could get you into a HUGE problem there… With those exceptions, I don't see a whole lot of opportunity for things to go screwy with multiple sessions - after all, most of the rest of DLEP is less of a "control session" and more of a "signaling/eventing" mechanism.

For shared media, it doesn't matter if concurrent access is from routers connected to same modem or from other nodes. Didn't we discuss this in Berlin? I remember the CDR was for rate when channel was idle. We discussed a third metric, the expected rate for this node, which is <= CDR.
Can you provide feedback on this topic after a chat with the Persistent guys? They would know how to deal with multiple routers (or hosts) to their radio's.


Teco


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