Subject: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 3 Mar 2014 16:31:58 +0100

Hi Henning,

Do you mean if the DLEP ACK messages are dropped then DLEP performance will
be below 70 percent and 30 percent losses? MANET protocols always have
percentages of errors.

So do I understand that if there is ACK messages in any MANET protocol
(which uses transport layer) then there are only three options as below. I
think AODV is already has option of ACK message but still it works perfect
with UDP,

AB

On Monday, March 3, 2014, Henning Rogge wrote:

> The reason for TCP instead of UDP is very simple.
>
> The WG decided quite some time ago that we follow a "stateful DLEP"
> approach.
>
> DLEP contains ACK messages, which means that you have three options:
>
> 1) You can implement DLEP as "stop and wait", which means a sender can
> only a single packet that has to be acknowledged and then waits for
> the ACK before sending another one.
>
> 2) You can implement a whole bunch of "sequence number", "sliding
> window" and "ack/retransmission" mechanisms. In fact this is a step
> towards reinventing the wheel depending how clever you want to do
> this.
>
> 3) You can switch to a reliable transport protocol.
>
> We decided to use option 3) for DLEP-05 because its the easiest to
> implement and does not kill performance like a "stop and wait"
> strategy.
>
> Henning Rogge
>
> On Mon, Mar 3, 2014 at 2:21 PM, Abdussalam Baryun
> <[email-masked] <javascript:;>> wrote:
> > Hi Stan,
> >
> > Thanks for you email, i want this draft to go ahead to WGLC with 04
> draft,
> > the 05 had not change only few word, but big changing of performance.
> >
> >  I don't totally disagree with the authors because I see they are doing
> big
> > effort to make the draft go forward which I agree and understand.
> However, I
> > will prepare my comments with good reason why not TCP and there were
> inputs
> > from WG before questioning and don't think the discussion ended.
> >
> > I think the reasons for going to TCP was not enough but the authors
> chosen
> > before UDP and WG adopted that. I will prepare why not TCP, but I think
> DT
> > should answer in its report first why not UDP then why TCP is with better
> > performance. The only reason I notice from DT was design issues.
> >
> > @DT
> > Please report : why not UDP in performance of DLEP as comparing TCP and
> UDP
> > when using DLEP performance. I understand design purposes but would
> think of
> > DLEP overall performance as well.
> >
> > AB
> >
> >
> > On Monday, March 3, 2014, Stan Ratliff (sratliff) wrote:
> >>
> >>
> >> On Mar 3, 2014, at 6:48 AM, Abdussalam Baryun <
> [email-masked] <javascript:;>>
> >> wrote:
> >>
> >> > Hi Chris,
> >> >
> >> > I did not want to join the DT, and still not getting their report, but
> >> > I want to discuss within WG list. I beleive editors should follow the
> >> > WG participants text amending, and follow consensus. I look forward to
> >> > comment on the DLEP on the list and in this meeting. Comments below,
> >> >
> >> > Regards
> >> > AB
> >> >
> >> > On 11/12/13, Dearlove, Christopher (UK) <
> [email-masked] <javascript:;>>
> >> > wrote:
> >> >> Wrong I'm afraid, both procedurally and practically. WGs can't write
> >> >> documents, that just isn't a viable approach. Documents are written
> by
> >> >> authors, or sometimes editors. The WG can reject a document. But
> that's
> >> >> not
> >> >> the same as writing one.
> >> >>
> >> >
> >> > I meant to say that DLEP draft is changing from using UDP to use TCP
> >> > without enough discussion on the WG list or final consensus. If
> >> > editors make the change in the draft which they already did, that will
> >> > affect the fairness of the final consensus and also the WG
> >> > discussions.
> >>
> >> I changed DLEP 05 to use TCP because the people on the design team
> wanted
> >> TCP. I appreciate that you have expressed dissent. But so far, your
> dissent
> >> is only one I've seen. If there are other working group participants
> that
> >> believe moving to TCP is a bad thing, I hope they will express that view
> >> here on the list. Otherwise, it looks like you are "in the rough" on
> this
> >> one.
> >>
> >> Heck, I'd even change the transport to IPX if it would help get DLEP to
> >> ratification. When we (the co-authors) first floated this draft, we were
> >> under the (obviously naive) impression that DLEP would be a "project".
> I'm
> >> not sure how, or why, it has morphed into a "career path". *Sigh*...
> That
> >> said, i'd really like to get this draft to WGLC before my grandchildren
> have
> >> grandchildren...
> >>
> >> Regards,
> >> Stan
> >>
> >>
> >> >
> >> > I feel now after the editors have made their decisions with the DT,
> >> > now I am forced to not discuss, or I am forced to be in a discouraged
> >> > position. It seems now it is better for me to leave the flow go into
> >> > DT decisions, and hopefully not all drafts take the same direction in
> >> > future,
> >> >
> >> >> From: [email-masked] <javascript:;> [mailto:
> [email-masked] <javascript:;>] On Behalf
> >> >> Of
> >> >> Abdussalam Baryun
> >> >> Sent: 12 November 2013 16:30
> >> >> To: Dowdell, John
> >> >> Cc: [email-masked] <javascript:;>
> >> >> Subject: Re: [manet] DLEP DT summary
> >> >>
> >> >> Hi John
> >> >>
> >> >> I have been very interested and was regular posting and reviewing the
> >> >> work
> >> >> but should not be excluded (there are others ). However, I thank you
> >> >> and the
> >> >> members of DT for your contributions, and always want to speed the
> >> >> process
> >> >> for DLEP but with best practices and awareness. In the last two
> meeting
> >> >> there were comments from the community that the DT should follow. The
> >> >> WG did
> >> >> not decide to give its job to the DT.
> >> >>
> >> >> I don't agree that the DT makes changes to the DLEP draft, the DT
> >> >> should
> >> >> report its recommendations to this list, so the WG decides and
> >> >> discusses
> >> >> what to do.
> >> >>
> >> >> AB
> >> >>
> >> >
> >> >> On Tuesday, November 12, 2013, Dowdell, John wrote:
> >> >> For the avoidance of doubt, please understand that I asked for an
> >> >> informal
> >> >> meeting at Berlin IETF that half way through became the Design Team.
> >> >> The
> >> >> meeting attendees were drawn from those who had regularly posted on
> >> >> DLEP
> >> >> since the 00 draft, and therefore were deemed to be most interested
> in
> >> >> getting to an RFC, as I was. Kindly lay off the lead author of DLEP.
> >> >
> >> > I am also, but big changes like using TCP need consensus, now with
> >> > draft changed I feel I have no interest in giving even a humm voice.
> >> >
> >> >>
> >> >> In the meantime, if anyone else is actively developing with DLEP
> >> >> (router or
> >> >> modem side) and is willing to directly contribute to the speedy and
> >> >> successful development of the draft, please post on the manet list
> and
> >> >> we
> >> >> will be in touch. One person joined the team since the first meeting
> in
> >> >> Berlin.
> >> >
> >> > I did not join the team, because I think it is with enough capacity,
> >> > and if me and other join it will become another MANET WG list.
> >> >
> >> >>
> >> >> For timescales and upcoming work, please listen to the DLEP
> >> >> presentation in
> >> >> the early part of the manet WG meeting at Vancouver.
> >> >>
> >> >
> >> > I agree that all to listen to each other, so community listen and then
> >> > the community to be listened to as well,
> >> >
> >> > _______________________________________________
> >> > manet mailing list
> >> > [email-masked] <javascript:;>
> >> > https://www.ietf.org/mailman/listinfo/manet
> >>
> >
> > _______________________________________________
> > manet mailing list
> > [email-masked] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/manet
> >
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 3 Mar 2014 16:34:39 +0100

Sorry, the question meant to consider if dropped acks messages were about
10-30 percent error.

AB

On Monday, March 3, 2014, Abdussalam Baryun wrote:

> Hi Henning,
>
> Do you mean if the DLEP ACK messages are dropped then DLEP performance
> will be below 70 percent and 30 percent losses? MANET protocols always have
> percentages of errors.
>
>> <[email-masked]> wrote:
>> > Hi Stan,
>> >
>> [email-masked]>
>> >> wrote:
>> >>
>> >> > Hi Chris,
>> >> >
>> [email-masked]>
>> >> > wrote:
>> >> said, i'd really like to get this draft to WGLC before my
>> grandchildren have
>> >> grandchildren...
>> >>
>> >> Regards,
>> >> Stan
>> >>
>> >>
>> >> >
>> >> >> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> >> >> Of
>> >> >> Abdussalam Baryun
>> >> >> Cc: [email-masked]
>> >> >> will be in touch. One person joined the team since the first
>> meeting in
>> >> >> Berlin.
>> >> >
>> >> > [email-masked]
>> > [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Mon, 3 Mar 2014 15:37:06 +0000

What you write make no sense at all. I am not even sure it has much to do
with my answer.

DLEP is not an "over the air" protocol... I also recommend to look up "stop
and wait" protocol.

Henning
On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" <[email-masked]>

---

From: "Snyder, Brian" <[email-masked]>
Date: Mon, 3 Mar 2014 15:42:14 +0000

Hi all, I am just getting started learning and understanding the MANET technology (DLEP). I was wondering if there are any good hands on training classes or online resources one can study? I have the RFC and IETF docs, but I find a good walkthrough helps it sink into my brain a little better…..   

Thanks,
Brian

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Mar 2014 12:05:52 +0100

Hi Henning,

I am not sure if there were consensus on to have stateful
communication of DLEP (did I miss that, not sure, please advise). I
think DLEP is abstract approach agreed on as -04. I think DLEP is
flexible bidirectional communication ( I will read draft-5/draft-4
again to make sure). However, I agree with DLEP-04 but still thinking
why must DLEP-05 and why not draft-04. My comments below,

On Monday, March 3, 2014, Kenning Rogge wrote:
>
> What you write make no sense at all. I am not even sure it has much to do with my answer.

It is related that you gave alternatives to DLEP communication with
router because of DLEP's ACK messages. TCP also has ACKs, and flow
control, so overloading channel. In any protocol ACKs are used for
loss or error possibilities.

>
> DLEP is not an "over the air" protocol... I also recommend to look up "stop and wait" protocol.

Yes, it is mentioned that in discussions, but still losses or errors
may occur in MANET scenarios of D2D (devices comm) or do you mean
there will be no drops/losses. I interested in ack/retransmit
technique or sequence numbers technique (ready no need to invint any
thing) as in AODV communication. So your alternative (2) is my choice
to make better DLEP performance as in DLEP-04. Why is TCP better than
UDP while we use ACKs, is it because possible high loss percentage in
channel?

However, I agree that my discuss may not be clear (sorry for this, but
I am motivated and happy to discuss) and I will have to organise my
comment better after finish my overall review of the DLEP change
including its performance. See you tomorrow,

Best regards,

AB
>
> Henning
>
> On Mar 3, 2014 4:31 PM, "Abdussalam Baryun" <[email-masked]> wrote:
>>
>> Hi Henning,
>>
>> Do you mean if the DLEP ACK messages are dropped then DLEP performance will be below 70 percent and 30 percent losses? MANET protocols always have percentages of errors.
>>
>> So do I understand that if there is ACK messages in any MANET protocol (which uses transport layer) then there are only three options as below. I think AODV is already has option of ACK message but still it works perfect with UDP,
>>
>> AB
>>
>>> The WG decided quite some time ago that we follow a "stateful DLEP" approach.
>>>

Yes IMHO, this option gives more flexibility, more independent and
more performance.

>>> > Thanks for you email, i want this draft to go ahead to WGLC with 04 draft,
>>> >  I don't totally disagree with the authors because I see they are doing big
>>> > effort to make the draft go forward which I agree and understand. However, I
>>> > will prepare my comments with good reason why not TCP and there were inputs
>>> > I think the reasons for going to TCP was not enough but the authors chosen
>>> > before UDP and WG adopted that. I will prepare why not TCP, but I think DT
>>> > Please report : why not UDP in performance of DLEP as comparing TCP and UDP
>>> > when using DLEP performance. I understand design purposes but would think of

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Mar 2014 12:54:40 +0100

Hi John,

So you mean low possibility of loss, so why not UDP? that is not
answered, the only answer was because DLEP is stateful and it has ACK
messages. So why not DLEP-04 while I am using realiable PHY as you
describe. In addition, even if there are reliability in PHY there may
be losses in other layers under MANET applicabilities, so that is why
DLEP-04 has ACKs, which I agree, but don't understand the TCP
importance in such communication scenarios.

AB

On 3/4/14, Dowdell, John <[email-masked]> wrote:
> Abdussalam
>
> May I re-iterate the points already made.
>
> DLEP is NOT an over the air protocol. DLEP works along the physical medium
> (copper, fibre, whatever) between the radio and its local router. Thus the
> Design Team consider there is a very low probability of loss of messages
> over this medium. How the radios exchange the relevant information with each
> other, and overcome the losses expected on any air interface, is for the
> radio manufacturer to decide and is generally referred to in the design team
> as "radio magic". The Design Team discussed this topic long and hard and the
> draft represents the consensus of the Design Team. Whether the manet working
> group will reach consensus on this matter is for the working group to
> decide, but it seems by far the most sensible direction to the Design Team.
>
> John
> -----Original Message-----
> From: Abdussalam Baryun [mailto:[email-masked]]
> Sent: 04 March 2014 11:06
> To: Henning Rogge
> Cc: MANET IETF; Dearlove, Christopher (UK); Stan Ratliff (sratliff);
> Dowdell, John
> Subject: DLEP performance with and without TCP (was Re: DLEP DT summary
>
> Hi Henning,
>
>>> will be below 70 percent and 30 percent losses? MANET protocols always
>>> have percentages of errors.
>>>
>>> (which uses transport layer) then there are only three options as below.
>>> I think AODV is already has option of ACK message but still it works
>>> perfect with UDP,
>>>
>>> AB
>>>
> 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, part of the Airbus Defence and Space
> division. Registered Office: Quadrant House, Celtic Springs, Coedkernew,
> Newport , NP10 8FZ. Registered in England and Wales under company number
> 04191036
>

---

From: Shawn Jury <[email-masked]>
Date: Tue, 4 Mar 2014 08:21:29 -0500

Hello AB,

     Here we are again with you stating you dislike something, but not telling us why you dislike it.  You are just asking us to explain the change to you.  

    I'll tell you that I wasn't part of the DT for DLEP, but I can see the benefit of using TCP.  Just some of the benefits:

*  No need to recreate a complex state machine in DLEP that would mimic TCP's behavior.  
*  TCP is an already existing reliable transport protocol (readily available). 
*  Simplifies the overall implementation of the protocol.
*  Addresses earlier concerns about how DLEP was a "stop and wait" protocol.

   With that said, please explain why you do not like TCP for DLEP.  You seem to agree that a reliable transport is needed (ACKs and SeqNums in -04), but just state that you don't like TCP and are in favor of creating a protocol that "gives more flexibility, more independent and more performance".  TCP meets the needs that are required for our purpose.

    Unless you can produce a valid argument of why you don't like it, I'm at a point where I'll just attribute your objections to white noise as there doesn't seem to be any substance behind them, nor much support from others on the list.

    If you have a technical argument of why we shouldn't use TCP, please send it to the list. 

Shawn

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Mar 2014 16:01:35 +0100

Hi Shawn,

Usually, the DT should report why TCP and not UDP, and IMHO, WG still did
not confirm its decision. Your reasons does not include any performance
issue comparing both transports or comparing both docs draft-04 and
draft-05.

My concerns are DLEP speed, overhead, and management. The beauty of
draft-04 is that it's link speed between devices should not always be with
high capacity, but for draft-05 there should be including that in the draft
to show its performance limits. Usually, you see thread subject DLEP with
TCP in last Aug, I am not alone wanting UDP (don't forget authors started
with UDP, Duke and Juliusz) regarding change problems see point below,
which made me say IMHO discussion was not enough.

http://www.ietf.org/mail-archive/web/manet/current/msg15566.html

http://www.ietf.org/mail-archive/web/manet/current/msg15568.html

I hope that answers some of my thoughts.
Regards
AB

On Tuesday, March 4, 2014, Shawn Jury wrote:

> Hello AB,
>
>      Here we are again with you stating you dislike something, but not
> telling us why you dislike it.  You are just asking us to explain the
> change to you.

If I say I like I mean I want or think is better, not totally sure.

>
>     I'll tell you that I wasn't part of the DT for DLEP, but I can see the
> benefit of using TCP.  Just some of the benefits:
>
>    With that said, please explain why you do not like TCP for DLEP.  You
> seem to agree that a reliable transport is needed (ACKs and SeqNums in
> -04), but just state that you don't like TCP and are in favor of creating a
> protocol that "gives more flexibility, more independent and more
> performance".  TCP meets the needs that are required for our purpose.
>
>     Unless you can produce a valid argument of why you don't like it, I'm
> at a point where I'll just attribute your objections to white noise as
> there doesn't seem to be any substance behind them, nor much support from
> others on the list.
>

---

From: Shawn Jury <[email-masked]>
Date: Tue, 4 Mar 2014 10:52:32 -0500

AB,

    As a co-author of the draft, there were many discussions prior to submission on UDP vs TCP.  Our decision of UDP was  because we truly believed this paragraph from the draft (which stated UDP prior to -05):

   This document specifies an implementation of the DLEP messages and
   data items running over the TCP transport, utilizing a well-known TCP
   Port number. It is assumed that DLEP running over other transport
   mechanisms would be documented separately.

   If there are situations where another transport protocols would be better, then an extension could be written (or whatever the best practice is for IETF drafts in this case).

   Based upon what I read in the old messages (to refresh my memory), there is just as much push for TCP as there was for UDP. IMHO, there was more for TCP.  You even linked a message where Teco was pushing for TCP in your reply to me.

   I've spent the better part of the last 8 years working with different radio vendors on a way to get a protocol like this to work.  Not once did anyone ever complain about which transport protocol was being used, nor did they ever talk about the connection between the router/radio being limited.  All the issues I have run into have been with radios that have a slightly different implementation and doesn't quite fit into a specific area (as recent as yesterday).  Of course, there are also so many waiting on the final draft from this working group, I'm wondering if they will ever get to implement anything.

   Please, continue pushing for justification on the transport protocol as I'm sure you believe it is very important.

   Thanks for your discussion.  I'll sit back again and watch as this becomes more and more of a career path :)

Shawn

On Mar 4, 2014, at 10:01 AM, Abdussalam Baryun wrote:

> Hi Shawn,
> 
> Usually, the DT should report why TCP and not UDP, and IMHO, WG still did not confirm its decision. Your reasons does not include any performance issue comparing both transports or comparing both docs draft-04 and draft-05. 
> 
> My concerns are DLEP speed, overhead, and management. The beauty of draft-04 is that it's link speed between devices should not always be with high capacity, but for draft-05 there should be including that in the draft to show its performance limits. Usually, you see thread subject DLEP with TCP in last Aug, I am not alone wanting UDP (don't forget authors started with UDP, Duke and Juliusz) regarding change problems see point below, which made me say IMHO discussion was not enough.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 4 Mar 2014 16:13:50 +0000

All, 

I also note that Martin Duke wound up contributing quite a bit to the design team effort; I do not recall any dissent from him at the time of the 05 draft. 

Now to address another couple of AB's comments: 
>> 
>> Usually, the DT should report why TCP and not UDP, and IMHO, WG still did not confirm its decision.

I'm not entirely sure what you mean here. The MANET WG has pretty much been, for as long as I've been involved, a group where (1) first an author (or a group of authors) submits a draft, and then (2) the WG comments (or 'confirms') that iteration of the draft. The Design Team acted in the role of "a really interested and active subset of the working group that committed to additional effort in order to enlighten the authors, and thereby, hopefully proceed the draft through an iteration or two faster than it has been going". The design team effort (along with that of the co-authors) has produced DLEP-05. Having the WG 'confirm' (or discuss) the 05 draft is what is happening right now.

>> Your reasons does not include any performance issue comparing both transports or comparing both docs draft-04 and draft-05. 
>> 

We've tried to explain on multiple occasions - there are *no* performance considerations. None. There are *no* packet loss considerations. None. This is because the protocol is completely bounded on a local Ethernet segment between a router and an "external modem". This is also because the protocol does not, in any way, shape, or form, touch the data plane. Data packets through the modem based network flow *exactly* as they would without DLEP running - that is, a packet would egress the router's Ethernet interface, be picked up by the external modem, and then transmitted over-the-air to a receiving station. So performance was considered, and declared to be a non-issue due to the design and implementation of the protocol. Which means we're back to Shawn's enumerated list below on why a TCP-based implementation is actually simpler than a UDP-based implementation. Yes, the ACKs flow, but they are TCP ACKs. Not something the DLEP protocol has to take into account, process, etc etc. 

Long story short - I'm in agreement with Shawn. So far, I haven't seen any technical justification for reconsidering the move to TCP. AB, you said:
>> 
>> My concerns are DLEP speed, overhead, and management.

I share those concerns. I just don't see how a move to TCP adversely impacts them. You'll need to provide more information to enlighten me. 

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Mar 2014 17:49:50 +0100

Hi Shawn,

If the WG wants draft 05 as DT decide to pass it instead of draft-04, I
will not argue, but I would ask if possible the WG adopts (and the authors
may continue authoring) the UDP DLEP as draft-04 for renew draft-00, as you
mentioned that separate DLEP documents. Thanks,

AB

On Tuesday, March 4, 2014, Shawn Jury wrote:

> AB,
>
>     As a co-author of the draft, there were many discussions prior to
> submission on UDP vs TCP.  Our decision of UDP was  because we truly
> believed this paragraph from the draft (which stated UDP prior to -05):
>
>    If there are situations where another transport protocols would be
> better, then an extension could be written (or whatever the best practice
> is for IETF drafts in this case).
>
>    Based upon what I read in the old messages (to refresh my memory),
> there is just as much push for TCP as there was for UDP. IMHO, there was
> more for TCP.  You even linked a message where Teco was pushing for TCP in
> your reply to me.
>
>    I've spent the better part of the last 8 years working with different
> radio vendors on a way to get a protocol like this to work.  Not once did
> anyone ever complain about which transport protocol was being used, nor did
> they ever talk about the connection between the router/radio being limited.
>  All the issues I have run into have been with radios that have a slightly
> different implementation and doesn't quite fit into a specific area (as
> recent as yesterday).  Of course, there are also so many waiting on the
> final draft from this working group, I'm wondering if they will ever get to
> implement anything.
>
>    Please, continue pushing for justification on the transport protocol as
> I'm sure you believe it is very important.
>
>    Thanks for your discussion.  I'll sit back again and watch as this
> becomes more and more of a career path :)
>
> Shawn
>
> > Usually, the DT should report why TCP and not UDP, and IMHO, WG still
> did not confirm its decision. Your reasons does not include any performance
> >     I'll tell you that I wasn't part of the DT for DLEP, but I can see
> the benefit of using TCP.  Just some of the benefits:
> >
> >     Unless you can produce a valid argument of why you don't like it,
> I'm at a point where I'll just attribute your objections to white noise as

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 4 Mar 2014 18:05:59 +0100

To abuse two metaphors at once: I have no horses in this fight....but let me stick my nose out anyways, and start with an anecdote....

I had some concerns with the initial design of an early version of DLEP, specifically how it used <some-other-thing-not-important-here-since-its-aincient-history-now> in a way I thought wrong. I explained in great details to the authors why I thought it wrong: my concerns, my reasoning, and the (unintended) consequences that I saw with that element of the DLEP design. The authors went away, came back after having thought it through, with an updated design that satisfied me. Not the design that *I* would have made, mind you, but a design that satisfied my concerns as I had articulated them. That's really all anyone can ask.

Now, the authors could do that *only* because they were fed sufficiently precise details, reasons, source material, and technical arguments that they had something to work with, and a reasonable expectation that they'd be able to estimate if the outcome would be satisfying. I'm 200% sure that had I been wrong on this issue, they would have come back with a - just as precise (and polite) - rebuttal, which also would have satisfied me by educating me as to how I was wrong. Again, for a rebuttal, they would have needed *precise*, detailed *technical* arguments from me to work with and rebut.

Had I just said "I don't like your design", I'd simply have been ignored - or asked to "put up the arguments - or shut up".  And, reasonably so, I might add. 

If *I* dislike something, then it's *my* job to identify what and why, and articulate that in ways that are actionable by those who I ask to take action. This may be the authors, and by the WG - or (if taking things further) by the chairs, AD, the IESG or the IAB.

In this concrete case, Abdussalam doesn't like the choice of TCP in DLEP. I think we all understand that - but that's not actionable. The WG needs precise details, reasons, source materials and technical arguments to work with.

Once the we, the WG, has those, and only then, can action be taken, either in form of a rebuttal or a changed design. It's Abdussalam's job to provide those precise details, reasons, source materials and technical arguments. The WG (nor the DLEP authors nor any design team) can - nor should - try to guess what they may be.

My personal opinion is, that Stan and the others have done an admirable job of *trying* to guess and try to provide an explanation and a rebuttal. If they have failed to do so to Abdussalam's satisfaction,  then it's *not* their fault - it's because they do not have precise details, reasons, source materials and technical arguments to work with and rebut (or take action on).

I am 200% sure that if Abdussalam (or anyone else) do provides such details, reasons, source materials and technical arguments, then these matters will get the attentive ears of the authors and design team. If not, then - and only then - is there a case to make to the WG or to the ADs or the IESG or the IAB. 

Until then, or absent that, there's little point in continuing this discussion since there's no chance of making constructive progress.

Best,

Thomas

Sent from my iPad

> On 4 mars 2014, at 17:13, "Stan Ratliff (sratliff)" <[email-masked]> wrote:
> 
> All, 
>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 4 Mar 2014 17:23:34 +0000

Thank you Thomas,

I was going to bite and had a long reply ready, but I will hold off as I think you may have summarized the difficulties some of us are having second guessing AB's objection.

I do not however think it is sensible to attempt a fork of DLEP-04 resulting in DLEP-05-TCP and DLEP-04-UDP.  Because: 

A) In the considered opinion of the authors, the design team, and the majority of the active participants of the WG, simplifying the protocol by using TCP will ease the development of many implementations, increasing it's likelyhood of becoming a popular standard.

B) The authors and end-user community only have time and inclination to implement 1 standard.

AB, if you are in London, please come and find me after the MANET WG meeting tomorrow and I will try to explain why the authors and DT decided on TCP.  I believe you may have some gaps in your understanding that I am perfectly happy to try to fill.

Also, may I kindly remind you that it is the authors who are presenting their proposal for the DLEP protocol to the MANET WG.  They are not beholden to the members of the DT, or WG, or the IETF.  We may raise concerns, but this is a forum for constructive criticism, and there is nothing to prevent Stan et.al. from picking up their protocol and going home with it.

Rick Taylor

Who has bitten after all...

________________________________________
From: manet [[email-masked]] on behalf of Thomas Heide Clausen [[email-masked]]
Sent: 04 March 2014 17:05
To: Stan Ratliff (sratliff); Abdussalam Baryun
Cc: MANET IETF
Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT summary

Best,

Thomas

Sent from my iPad

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 4 Mar 2014 17:36:06 +0000

I'm not sure I've ever seen a forked protocol. There are cases like OSPF where v3 has not replaced v2 but lives alongside it. But they have an important difference, as well as being many years apart.

However two separate protocols alongside each other doing the same thing both trying to get through the IESG? I think most of us who have pushed protocols through the process would estimate the chances of success for both as close enough to zero to consider it that. And it would both reduce the probability and increase the delay of one. Which makes it about the most unattractive proposition that could be offered to the authors.

--  
Christopher Dearlove
[email-masked]

> On 4 Mar 2014, at 17:23, Rick Taylor <[email-masked]> wrote:
> 
> Thank you Thomas,
>

---

From: Joe Macker <[email-masked]>
Date: Tue, 4 Mar 2014 12:40:35 -0500

Thank you all for taking the time to provide your observations/opinions.

In my observation as co-chair there was a strong consensus among the developers and authors to go with TCP as the requirement in the present instantiation of the DLEP specification. As many have mentioned this is not an over-the-air protocol.  This decision was reported out at the last Vancouver WG meeting in slides and minutes in a clear manner you can go back and check.  The authors have provided rationale for their decision.

Moving forward with one specification is my strong recommendation. I am not a fan of forking off a separate specification at this point.  I think the WG and the DT is beyond this design point.

-Joe

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 4 Mar 2014 19:10:51 +0100

> On 4 mars 2014, at 18:36, Christopher Dearlove <[email-masked]> wrote:
> 

There is that process issue, and Chris is entirely right about that. 

If the WG decides to go down that path, then we are back with needing to make the case to the IESG as to why we need two protocols for the same thing...and for that, were back at needing sufficiently precise details, reasons, source material, and technical arguments that the IESG (who, generally speaking, are a bunch of smart - but overworked - cookies) will understand and agree with.

Thomas

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 4 Mar 2014 18:11:18 +0000

… I can't help it….

>  I am not a fan of forking off a separate specification at this point. 

I'll be a bit stronger: It would be a forking mess. 

There, I said it. 

Regards,
Stan

---

From: Joe Macker <[email-masked]>
Date: Tue, 4 Mar 2014 13:23:26 -0500

Yeah good one Stan..;-)

Let me be clearer on two points:

(1) I will not support any such proposal to work on two documents at this point! 
(2) Also I am satisfied the authors and the DT have historically discussed at length the issues and decided on a consensus strategy.

We will move forward with one specification.
-Joe

---

From: <[email-masked]>
Date: Tue, 4 Mar 2014 20:33:25 +0000

Worth noting that things that in theory can have multiple transports in practice often don't.

BEEP? only TCP use is defined and used in a profile. Bundle protocol is pretty much over TCP.
Efforts to move http over other transports like sctp have gone nowhere much.

Some things like NFS do exist in more than one flavour, for good dataplane reasons - but it's rare.

(I vocally loathed PPPoE as a transport, back in the day. still do.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: manet [[email-masked]] On Behalf Of Shawn Jury [[email-masked]]
Sent: 04 March 2014 15:52
To: Abdussalam Baryun
Cc: MANET IETF
Subject: Re: [manet] DLEP performance with and without TCP (was Re: DLEP DT     summary

AB,

Shawn

---

From: Brian Adamson <[email-masked]>
Date: Tue, 4 Mar 2014 17:52:00 -0500

I think TCP can work fine for many DLEP usecases.  And, as an idea, if there are some deployment cases where the DLEP connection needs service a little different than out-of-the-box TCP behavior, there are relatively straightforward approaches that can be used to "wrap" around the TCP connection the endpoints see.  For example, we (NRL) have implemented a SOCKS-based proxy for TCP connections that morphs them into NORM unicast flows (a reliable UDP protocol (RFC 5740) that does unicast as well as multicast) and can even provide pre-provisioned fixed-rate operation (thus avoid TCP slow start delays, etc) with reliable data delivery to the TCP connection content.  No changes are required on the endpoints … they just experience a nice speedy connection.  Others have done similar work to proxy TCP flows in various ways for various purposes.  So I don't think the DLEP spec would need to be mucked up.  It would be a matter of system configuration to provide the proxy support.  Compatibility with SOCKS (RFC 1928) could be suggested as an enabler for this sort of thing, but if it's a straightforward TCP usage, then that pretty much comes for free …

cheers,

Brian