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

["Taylor, Rick" <[e-mail]>]

> From: Teco Boot [mailto:[e-mail]]
> Subject: Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re:
> notes DLEP meeting @ IETF88)
> Op 15 nov. 2013, om 11:33 heeft Taylor, Rick <[e-mail]>
> het volgende geschreven:
>
> >
> > 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
> >
> > 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

I'll send my thoughts on this later.

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

Isn't the client aware the session is established when it receives the Peer_Accept (I renamed the ACK) with status code?

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

+1 Yes, agreed, it is, that's what I meant by listen() in step 1.

> After connection, Peer_Discovery packets SHOULD continue to be sent, for
> the following reasons:
>  - 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).

+1 Yes, I just didn't put this in the diagram for simplicity.

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