Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

[Martin Duke <[e-mail]>]

I'm comfortable with router-initiated processes, though it doesn't seem to
match up with things that Stan and Teco have said recently.
On Nov 14, 2013 2:17 AM, "Taylor, Rick" <[e-mail]> wrote:

> Martin,
>
> I think the discussions passed like two ships in the night, but I believe
> we have now moved to peer discovery being a router-initiated process for
> exactly the reason you describe.
>
> The router can keep strobing for interested modems, and modems can decide
> to connect to the advertising router if they wish.
>
> If you check back through the archive, the recent thread called "DLEP
> session establishment" has the discussion.
>
> Sorry, this list has gone quite mad since Vancouver, but I suppose that
> shows interest by the DT!
>
> And thanks for taking a personal interest even if you are moving off your
> current project.
>
> Cheers,
>
> Rick
>
> > -----Original Message-----
> > From: [e-mail] [mailto:manet-dlep-rg-
> > [e-mail]] On Behalf Of Duke, Martin
> > Sent: 12 November 2013 16:57
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88
> >
> > Teco,
> >
> > It seems like there are two competing proposals for session
> > initialization. Yours:
> >
> > >> Router                    Modem   Message Description
> > >> ====================================================================
> > >>
> > >> <-------Peer Discovery---------   Modem initiates discovery
> > >>                                  with server TCP port ...
> > >> <-------Peer Discovery---------   Repeats discovery forever
> > >> ...
> > >>
> > >> ------------TCP SYN----------->   Router initiates TCP connection to
> > TCP server
> > >>                                  port from Peer Discovery
> > >> <---------TCP SYN ACK----------   Modem part of TCP connection set up
> > >> ------------TCP ACK----------->   Router finishes TCP connection set
> up
> > >>
> > >> -----------Peer Offer--------->   Router starts DLEP session with
> Offer
> > >> <--------Peer Offer ACK--------   Modem joins in DLEP session with
> > Offer Ack
> > >> ---------Peer Offer ACK------->   Router completes DLEP session with
> > Offer Ack
> >
> > And Stan's:
> >
> > Router                  Modem               Message Description
> > ======================================================
> > <------------------------ Peer Discovery     Modem initiates discovery
> via
> > MCAST UDP.
> > Peer Offer    -------------------------->     Response to discovery,
> > basically an "I'm here"
> >                                               response. Contains TCP
> > address/port for
> >                                                       subsequent
> connection.
> > <------------------------- TCP SYN
> > TCP SYN ACK ----------------------->
> >  <------------------------- ACK         (Standard TCP 3-way handshake)
> >  <-------------------------- Peer Initialization (New message). The Peer
> > Init message contains, for example, all of the MANDATORY metric TLVs that
> > the modem supports. It's a way to get the DLEP control session
> > initialized.
> >
> > ... and I suppose Stan, if he was finishing the example, would need two
> > additional messages to complete session negotiation.
> >
> > A bunch of comments:
> > 1) Stan's stated purpose to flip the SYN is to put the server
> > implementation at the router. Frankly that's good enough for me unless
> > Teco has counter-arguments.
> > 2) Given #1, I agree with Stan the Peer Offer has to come outside the TCP
> > connection to provide the port number.
> > 3) I'm not particularly convinced that we have to strip all the TLVs and
> > whatnot out of the Peer Discovery/Peer Offer messages and put them in a
> > new Peer Initialization exchange. It's a small thing either way, but I'm
> > in favor of having fewer messages if we can afford it, and refusing
> > sessions prior to a TCP handshake if we can do it.
> >
> > Martin
> >
> > -----Original Message-----
> > From: Teco Boot [mailto:[e-mail]]
> > Sent: Tuesday, November 12, 2013 8:33 AM
> > To: Duke, Martin
> > Cc: [e-mail]
> > Subject: Re: notes DLEP meeting @ IETF88
> >
> >
> > Op 12 nov. 2013, om 17:04 heeft Duke, Martin <[e-mail]>
> het
> > volgende geschreven:
> >
> > > It feels like the terminology is a bit jumbled here. The "Peer
> > Discovery" contains all the session parameters for the modem. The "Peer
> > Offer" in effect acknowledges these and contains relevant parameters for
> > the Router. The "Peer Offer ACK" confirms the modem's acceptance of
> these?
> > Why do we have to confirm the confirmation?
> >
> > We have to come back to this. Recent posts rename couple of messages.
> > Discovery is just the advertisement, where DLEP session setup takes care
> > of transfer of all supported TLVs.
> >
> > The Peer Offer would be renamed to Peer Initialization, with three-way
> > handshake.
> >
> > Maybe better rename Peer Discovery to DLEP Modem Advertisement.
> >
> > All of this has to do with rework because we transfer to TCP were we have
> > the connection setup.
> >
> > Teco
> >
> >
> > >
> > > -----Original Message-----
> > > From: Teco Boot [mailto:[e-mail]]
> > > Sent: Monday, November 11, 2013 9:57 PM
> > > To: Duke, Martin
> > > Cc: [e-mail]
> > > Subject: Re: notes DLEP meeting @ IETF88
> > >
> > >
> > > Op 11 nov. 2013, om 22:45 heeft Duke, Martin <[e-mail]>
> > het volgende geschreven:
> > >
> > >> What is the purpose of the second Peer Offer ACK?
> > >
> > > It informs the modem that router accepts the Modem Peer Offer. Then
> both
> > peers of the session knows session setup was successful. If the Router
> > does not accept the Peer Offer Ack (e.g. version mismatch), it sends an
> > error and / or closes the connection.
> >
> > >
> > > Teco
> > >
> > >
> > >>
> > >> -----Original Message-----
> > >> From: Teco Boot [mailto:[e-mail]]
> > >> Sent: Monday, November 11, 2013 1:39 PM
> > >> To: Duke, Martin
> > >> Cc: [e-mail]
> > >> Subject: Re: notes DLEP meeting @ IETF88
> > >>
> > >> Let's come back to this topic after we completed TCP connection and
> > DLEP session management. Probably the issue is solved by then.
> > >>
> > >> Please comment on the TCP connection setup and maintenance. Below the
> > proposal, adjusted after comments from Stan and Henning.
> > >>
> > >> Router                    Modem   Message Description
> > >> ====================================================================
> > >>
> > >> <-------Peer Discovery---------   Modem initiates discovery
> > >>                                  with server TCP port ...
> > >> <-------Peer Discovery---------   Repeats discovery forever
> > >> ...
> > >>
> > >> ------------TCP SYN----------->   Router initiates TCP connection to
> > TCP server
> > >>                                  port from Peer Discovery
> > >> <---------TCP SYN ACK----------   Modem part of TCP connection set up
> > >> ------------TCP ACK----------->   Router finishes TCP connection set
> up
> > >>
> > >> -----------Peer Offer--------->   Router starts DLEP session with
> Offer
> > >> <--------Peer Offer ACK--------   Modem joins in DLEP session with
> > Offer Ack
> > >> ---------Peer Offer ACK------->   Router completes DLEP session with
> > Offer Ack
> > >>
> > >> <=============================>   DLEP session is established
> > >>
> > >> <--------Peer Heartbeat--------   Heartbeats when no other messages
> > >> ---------Peer Heartbeat------->     between Router and Modem
> > >>
> > >> <---------Neighbor Up ---------   Modem sends Neighbor Up with metrics
> > >>                                  No DLEP Ack required
> > >>
> > >> <-------Neighbor Update--------   Modem Neighbor metrics update
> > >> ...
> > >> <-------Neighbor Update--------
> > >> ...
> > >> <--------Neighbor Down---------   Modem sends Neighbor Down
> > >>
> > >> When somethings goes wrong or down state is scheduled, DLEP session
> > >> terminates with TCP connection mechanism. Before, a Peer Error MAY be
> > >> send.
> > >>
> > >> <----------Peer Error----------   Optional Modem error report
> > >> <-------TCP RESET or FIN-------   Modem terminates session
> > >>      completed following
> > >>         TCP procedure
> > >> or
> > >> -----------Peer Error--------->   Optional Router error report
> > >> --------TCP RESET or FIN------>   Router terminates session
> > >>      completed following
> > >>         TCP procedure
> > >>
> > >> Teco
> > >>
> > >> Op 11 nov. 2013, om 19:48 heeft Duke, Martin <[e-mail]>
> > het volgende geschreven:
> > >>
> > >>> We must be talking past each other. In Section 11 of DLEP-04:
> > >>>
> > >>> A Peer Discovery Message received from a modem that is already in
> > >>> session MUST be processed as if a Peer Termination Message had been
> > >>> received. A router implementation MAY then process the received Peer
> > >>> Discovery Message.
> > >>>
> > >>> The plain language interpretation of this is that a modem that
> > continues to send out Peer Discovery messages to find new peers will
> > trigger resets of existing sessions.
> > >>>
> > >>> Perhaps the root problem is that we haven't really done a scrub for
> > the implications of using TCP on all of the reliability mechanisms from
> > previous drafts. I get confused on whether or not we're precluding UDP
> > implementations, but maybe the right answer is to simply delete this
> > provision.
> > >>>
> > >>> -----Original Message-----
> > >>> From: Teco Boot [mailto:[e-mail]]
> > >>> Sent: Monday, November 11, 2013 10:31 AM
> > >>> To: Duke, Martin
> > >>> Cc: [e-mail]
> > >>> Subject: Re: notes DLEP meeting @ IETF88
> > >>>
> > >>> I might have missed some context here, discussed during post-meeting
> > meeting.
> > >>>
> > >>> Do you think there is a need for terminating the TCP connection,
> other
> > than what TCP can provide? Maybe you had something in mind with heartbeat
> > turned off and blocked TCP port. I prefer a non-blocking implementation.
> > For a crashed DLEP agent, I can think of a Peer Order with Reset TLV,
> > where router resets the modem. Would be similar to AT!RESET.
> > >>>
> > >>> Teco
> > >>>
> > >>>
> > >>> Op 11 nov. 2013, om 17:33 heeft Duke, Martin <[e-mail]
> >
> > het volgende geschreven:
> > >>>
> > >>>> Teco,
> > >>>>
> > >>>> Although I follow that you want multiple peer sessions per modem,
> I'm
> > having trouble parsing what your prescription is to address the peer
> > session teardown problem I pointed out.
> > >>>>
> > >>>> Martin
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Teco Boot [mailto:[e-mail]]
> > >>>> Sent: Monday, November 11, 2013 7:48 AM
> > >>>> To: Duke, Martin
> > >>>> Cc: [e-mail]
> > >>>> Subject: Re: notes DLEP meeting @ IETF88
> > >>>>
> > >>>> I think we keep Peer Discovery message generation and DLEP session
> > maintenance separate. This keeps state machines less complex, less code,
> > less bugs, increased functionality.
> > >>>>
> > >>>> Having multiple DLEP session to same modem is related. If we support
> > it, sending Peer Discovery messages shall not be stopped after first
> > session.
> > >>>>
> > >>>> Reason why I need multiple sessions: about half of modems I have to
> > support have multiple ethernet ports. They serve multiple unrelated
> > networks, there is no single connected router. Some modems are 6 digit $,
> > we have to share these expensive assets. And they fully support it;).
> > >>>>
> > >>>> Teco
> > >>>>
> > >>>>
> > >>>> Op 11 nov. 2013, om 16:30 heeft Duke, Martin <
> [e-mail]>
> > het volgende geschreven:
> > >>>>
> > >>>>> Teco,
> > >>>>>
> > >>>>> Yes, this point was at the very end. The current spec says that if
> > the router receives a Peer Discovery message it must terminate any
> > existing session with that modem. Clearly this is not acceptable behavior
> > if the modem is continuing to multicast Peer Discovery messages when a
> > peer session exists.
> > >>>>>
> > >>>>> There are other ways to solve this problem, but the reply I got
> back
> > was that there was no reason to keep seeking routers once a peer session
> > exists. If there's disagreement on this point I'm happy  to back off the
> > assertion that it's settled.
> > >>>>>
> > >>>>> Martin
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Teco Boot [mailto:[e-mail]]
> > >>>>> Sent: Friday, November 08, 2013 10:59 PM
> > >>>>> To: Duke, Martin
> > >>>>> Cc: DLEP Research Group ([e-mail])
> > >>>>> Subject: Re: notes DLEP meeting @ IETF88
> > >>>>>
> > >>>>> Good summary, thanks. Let's only post the summary to the MANET ML.
> > >>>>> Having minutes archived on DLEP-RG ML would be fine, I think.
> > >>>>>
> > >>>>> On 7: It was not discussed during our meeting, at least not were I
> > was present. And I don't think this is a good idea. It is not needed and
> > blocks more advanced usage of DLEP. Let's not have a restriction in that
> a
> > router or modem has only a single DLEP peer.
> > >>>>>
> > >>>>> Teco
> > >>>>>
> > >>>>> Op 8 nov. 2013, om 21:40 heeft Duke, Martin <
> [e-mail]>
> > het volgende geschreven:
> > >>>>>
> > >>>>>> Thanks Ron. That matches the notes I have. I might also add this
> > summary of what I think we agreed on in terms of changing/clarifying the
> > spec, which perhaps is more interesting than the play-by-play:
> > >>>>>>
> > >>>>>> 1. There are no metric TLVs it is MANDATORY for the Router to
> > process.
> > >>>>>> 2. The modem MUST report MDRT, MDRR, CDRT, and CDRR in the Peer
> > Discovery message, and make a best effort to accurately report these
> > metrics subsequently.
> > >>>>>> 3. The modem and router MUST include DLEP version in Peer
> Discovery
> > and Peer Offer messages.
> > >>>>>> 4. The modem MUST include a Heartbeat Interval/Threshold TLV in
> its
> > Peer Discovery messages. It is STRONGLY RECOMMENDED that the Interval be
> a
> > nonzero value.
> > >>>>>> 5. The modem MUST include all metric TLVs it reports in the Peer
> > Discovery Message to allow the router to initialize its session control
> > block.
> > >>>>>> 6. The Router MUST NOT include metric TLVs in a Link
> > Characteristics Request message that were not in the session's Peer
> > Discovery message.
> > >>>>>> 7. The modem MUST NOT send Peer Discovery messages if it has an
> > existing Peer Session.
> > >>>>>> 8. Both router and modem MUST send a Heartbeat Message to the peer
> > if it has sent no DLEP message in an interval equivalent to the Heartbeat
> > Interval value in the Peer Discovery Message. It MAY send a Heartbeat
> > Message in every instance of the interval regardless of any other DLEP
> > traffic.
> > >>>>>> 9. Both router and modem MUST reset their Heartbeat timer when any
> > DLEP message arrives from the peer.
> > >>>>>> 10. The Heartbeat Interval/Threshold TLV becomes a "Heartbeat
> > Interval TLV." Any DLEP peer is free to set any threshold for terminating
> > the peer session as long as it equals or exceeds two Heartbeat Intervals,
> > unless the Heartbeat Interval is zero.
> >
> > >>>>>> 11. We will combine Expected Forwarding Time and Latency TLVs into
> > a single, well-defined TLV.
> > >>>>>> 12. Delete the Resources TLVs.
> > >>>>>> 13. Keep the RLQ TLV, but Rick and Stan will formulate a stricter
> > definition. There will be no other link quality TLVs (e.g. BER, packet
> > delivery rate, SINR, etc) in the next draft.
> > >>>>>> 14. Stan to add clarifying language on how multicast neighbors
> > work, in line with what he said at the meeting.
> > >>>>>>
> > >>>>>> As Ron said, the form of the Credits TLVs are unresolved at this
> > moment.
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Velt, R. (Ronald) in 't [mailto:[e-mail]]
> > >>>>>> Sent: Thursday, November 07, 2013 5:58 PM
> > >>>>>> To: Ulrich Herberg
> > >>>>>> Cc: [e-mail]; [e-mail];
> > >>>>>> [e-mail]; Duke, Martin; Teco Boot
> > >>>>>> ([e-mail]); [e-mail]; Henning Rogge
> > >>>>>> ([e-mail]); [e-mail]; [e-mail]
> > >>>>>> Subject: RE: notes DLEP meeting @ IETF88
> > >>>>>>
> > >>>>>> I leave that up to the DLEP veterans to decide. They may want to
> > >>>>>> "redact" these notes a bit ;-)
> > >>>>>>
> > >>>>>> Ronald
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Ulrich Herberg [mailto:[e-mail]]
> > >>>>>>> Sent: vrijdag 8 november 2013 2:44
> > >>>>>>> To: Velt, R. (Ronald) in 't
> > >>>>>>> Cc: [e-mail]; [e-mail];
> > >>>>>>> [e-mail]; [e-mail]; Teco Boot
> > >>>>>>> (teco@inf- net.nl); [e-mail]; Henning Rogge
> > >>>>>>> ([e-mail]); [e-mail]; [e-mail]
> > >>>>>>> Subject: Re: notes DLEP meeting @ IETF88
> > >>>>>>>
> > >>>>>>> Thanks. Do you want to send them out to the MANET mailing list?
> > >>>>>>>
> > >>>>>>> On Thu, Nov 7, 2013 at 5:40 PM, Velt, R. (Ronald) in 't
> > >>>>>>> <[e-mail]>
> > >>>>>>> wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> Please find attached my *raw* notes of our meeting on Tuesday.
> > >>>>>>> Disclaimer: Neither completeness nor correctness are guaranteed.
> > >>>>>>>>
> > >>>>>>>> Best regards,
> > >>>>>>>> Ronald in 't Velt
> > >>>>>>>>
> > >>>>>>>> ----
> > >>>>>>>> TNO Technical Sciences
> > >>>>>>>>
> > >>>>>>>> Network Technology dept.
> > >>>>>>>> ----
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
> > >>>>>>>> Indien u niet
> > >>>>>>> de geadresseerde bent of dit bericht abusievelijk aan u is
> > >>>>>>> toegezonden, wordt u verzocht dat aan de afzender te melden en
> > >>>>>>> het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid
> > >>>>>>> voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt
> > >>>>>>> en voor schade, van welke aard ook, die verband houdt met
> risico's
> > verbonden aan het elektronisch verzenden van berichten.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> This message may contain information that is not intended for
> > you.
> > >>>>>>>> If you
> > >>>>>>> are not the addressee or if this message was sent to you by
> > >>>>>>> mistake, you are requested to inform the sender and delete the
> > >>>>>>> message. TNO accepts no liability for the content of this
> > >>>>>>> e-mail, for the manner in which you use it and for damage of any
> > >>>>>>> kind resulting from the risks inherent to the electronic
> > transmission of messages.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
> > Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is
> > toegezonden, wordt u verzocht dat aan de afzender te melden en het
> bericht
> > te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van
> > deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke
> > aard ook, die verband houdt met risico's verbonden aan het elektronisch
> > verzenden van berichten.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> This message may contain information that is not intended for you.
> > If you are not the addressee or if this message was sent to you by
> > mistake, you are requested to inform the sender and delete the message.
> > TNO accepts no liability for the content of this e-mail, for the manner
> in
> > which you use it and for damage of any kind resulting from the risks
> > inherent to the electronic transmission of messages.
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
> > _______________________________________________
> > manet-dlep-rg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> 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
>