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

[Rick Taylor <[e-mail]>]

The problem as I see it with the modem initiated discovery process is the extra ACK required via UDP from the router:

Router                         Modem
=====================
<--------------------- Peer Discovery
I'm here (UDP) -------------------->
<----------------------- TCP connect

Rather than:

Router                         Modem
=====================
Peer Advert -------------------->
<----------------------- TCP connect

Just one less step with unreliable transport.

Can you describe what advantages you see with Modem initiated discovery?

Cheers,

Rick

________________________________________
From: [e-mail] [[e-mail]] on behalf of Henning Rogge [[e-mail]]
Sent: 14 November 2013 15:20
To: Martin Duke
Cc: Duke, Martin; DLEP Research Group ([e-mail]); Teco Boot; Taylor, Rick
Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

I still prefer the UDP peer discovery sent by the radio.

Henning Rogge

On Thu, Nov 14, 2013 at 4:19 PM, Martin Duke <[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>



--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan
_______________________________________________
manet-dlep-rg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/manet-dlep-rg