Subject: [manet] DLEP and TCP

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2013 15:03:58 +0200

Dear list,

At the Berlin meeting, we were informed that DLEP is going to switch
to using TCP as transport.  Using TCP for transporting what is
real-time data is a little bit suprising to me.

Could I most humbly request the rationale for switching DLEP to TCP?

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 7 Aug 2013 15:09:38 +0200

> Could I most humbly request the rationale for switching DLEP to TCP?

Part of the rationale was that DLEP is transporting only database 
changes between radio and router. If any of this changes has been lost, 
the database of the router might stay inconsistent for quite some time.

The current DLEP draft has the concept of acknowledgements between radio 
and router to make sure that this doesn't happen, but acknowledgements 
present us with a new problem.

Either we create a "stop and wait" style protocol which waits for each 
acknowledgement before sending the next data packet, or we need to add 
sequence numbers to data and acknowledgement.

Because DLEP updates might not make sense in the wrong order, we would 
have to start reproducing parts of TCP with buffering, windows and acks.

Switching to a reliable transport protocol solves most of this problems.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Teco Boot <[email-masked]>
Date: Wed, 7 Aug 2013 16:24:37 +0200

To add a few other mentioned arguments:
 - link between peers is a high speed link, there shouldn't be much difference in delay
 - many radio's have already a TCP stack (e.g. web server for management)
 - shortening the DLEP draft by reusing what is already available makes a lot of sense
 - where DLEP is used on non-IP links (e.g. within a chassis), there has to be a reliable transport protocol. standardization of such is not a task for IETF. the draft will say: if there is an IP link, TCP is used for reliable transport with peer.

Of course peer discovery is not TCP.
 
Teco

Op 7 aug. 2013, om 15:09 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> Part of the rationale was that DLEP is transporting only database changes between radio and router. If any of this changes has been lost, the database of the router might stay inconsistent for quite some time.
> 
> The current DLEP draft has the concept of acknowledgements between radio and router to make sure that this doesn't happen, but acknowledgements present us with a new problem.
> 
> Either we create a "stop and wait" style protocol which waits for each acknowledgement before sending the next data packet, or we need to add sequence numbers to data and acknowledgement.
> 
> Because DLEP updates might not make sense in the wrong order, we would have to start reproducing parts of TCP with buffering, windows and acks.
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 7 Aug 2013 14:45:50 +0000

Completely agree with what Henning and Teco have said. I'd like to elaborate just a tad on one of Teco's points: 

> - link between peers is a high speed link, there shouldn't be much difference in delay

DLEP runs *only* on the local radio-to-router link. It is *not* specified to run over the RF.  At least in the networks I've deployed, the local radio-to-router link is typically a FastEthernet. Secondly, we're only talking about the DLEP control traffic itself - there's no impact to data traffic over the RF. Given all of that, plus picking up the guaranteed delivery, moving to TCP doesn't seem onerous.

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Thu, 8 Aug 2013 15:56:56 +0000

I'm a little concerned about flow control messages working over TCP. We're looking at an application that emphasizes low latency and are trying to operate with very small queues at the radio; to do this without creating idle time at the radio requires tight bounds on when credit grants get to the router.

In general a non-greedy application (like DLEP's control plane) running TCP over an Ethernet connection should not trigger many packet losses, but I'm concerned about both occasional loss-related delays, and the Nagle algorithm raising the bound on control message delivery time.

Might we separate flow control from the TCP stream, just like Peer Discovery messages?

Martin Duke
Boeing Research & Technology

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: Wednesday, August 07, 2013 10:46 AM
To: Teco Boot
Cc: [email-masked] List
Subject: Re: [manet] DLEP and TCP

Regards,
Stan

>> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg,
>> Germany

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 8 Aug 2013 16:44:27 +0000

Martin, 

> In general a non-greedy application (like DLEP's control plane) running TCP over an Ethernet connection should not trigger many packet losses, but I'm concerned about both occasional loss-related d…

Good point.

> Might we separate flow control from the TCP stream, just like Peer Discovery messages?

That's an alternative. What I was envisioning, though, was a fairly simple implementation: For discovery, a radio would send a packet to a local subnet multicast address (assigned by IANA, with both an IPv4 and a v6 assignment), effectively saying "Hello! Any DLEPers out there?" The router would respond with a UDP packet saying "I'm here. Connect to me using address 'blah', port number 'foo''" (with the port number having an IANA assigned default). And that would be the end of the "UDP-ness"… ;-) Everything else could then shift over to the TCP-based connection. Simple, straightforward, something that even I could code… ;-) 

What you're suggesting does increase the complexity by a bunch. Specifically, I worry about whether there's an *implied* sequencing of messages between the TCP and UDP-based messages in that mode. For example, let's say the radio sends a Neighbor Update for a link metric update, and some flow control messages on the UDP socket. Is there a relationship between the two? And would the router have to implicitly (or explicitly) figure out what the relationship is? 

Your concern is making me wonder whether moving to TCP is really a good thing… or if we should just "bite the bullet", and fix the UDP issues. I'm starting to think that a "stop and wait" type of protocol really wouldn't be exceedingly nasty for something as light as DLEP…

Regards,
Stan

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 08 Aug 2013 09:59:45 -0700

Consider running the DLEP traffic over NORM???

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Aug 2013 20:16:30 +0200

Of we build flow control over UDP, how to handle loss? Why would it perform better than TCP?
Doesn't the push option enforce direct delivery? Nagle can be turned off, I think.

My personal opinion is to move flow control out of the base spec. I would run queuing and congestion management on the bottleneck, which is the radio.

We discussed DLEP for (groups of) diffserv codepoints. Would be needed for flow control also. Or having a queue depth on radio near to zero, but this brings the requirement for near to zero delay flow control.

Teco

---

From: <[email-masked]>
Date: Thu, 8 Aug 2013 22:52:37 +0100

TCP's congestion control and backoff will limit transmission on a loaded link - when you would need something like DLEP the most. TCP timers (delayed acks and system timers, not just Nagle) are counterproductive here.

The only thing I can think of worse than running DLEP over TCP would be some sort of http/xml/soap thing, with layers of unneeded cruft. Or possibly  DLEP over PPPoE. Have you considered that?

Lloyd Wood
http://sat-net.com/L.Wood/router-modem-integration

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stan Ratliff (sratliff) [[email-masked]]
Sent: 08 August 2013 17:44
To: Duke, Martin
Cc: [email-masked]
Subject: Re: [manet] DLEP and TCP

Martin,

Good point.

Regards,
Stan

---

From: Justin Dean <[email-masked]>
Date: Thu, 8 Aug 2013 18:05:17 -0400

If dlep is only running radio to router and not going over the air NORM may provide more control over point to point delay and backoff delay.  Care and direction would have to be given to provide sane settings.  While I think NORM would be a better protocol fit it may needlessly burden any actual implementation when TCP might work well enough and is already supported.  I do think it is a better fit however.

Justin

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Aug 2013 08:04:51 +0200

Sorry, I think your comment is not helpful.
The peer link (between router and radio) must not be the bottleneck. This need to be stated in the draft.
If the link was highly loaded, I can imagine TCP works much better than a bad designed protocol on UDP.

Yes, we considered xml/json but decided to stay away from that.

DLEP over a VLAN was considered some time ago, see mail archive for details. This has to do with L2 filters on the modem, for having DLEP multicast traffic only on the router-modem link and not on the RF link. Outcome was to stay away from that. Maybe this need more discussions and more text in the draft.

Teco

---

From: <[email-masked]>
Date: Fri, 9 Aug 2013 07:16:12 +0100

I think the problem here lies in not knowing how to design protocols on UDP.

Other groups - notably IRTF DTNRG - have had the effective outcome of "communication design is hard, let's just use TCP".

Lloyd Wood

________________________________________
From: Teco Boot [[email-masked]]
Sent: 09 August 2013 07:04
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] DLEP and TCP

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Aug 2013 08:22:23 +0200

On 08/09/2013 08:16 AM, [email-masked] wrote:
> Other groups - notably IRTF DTNRG - have had the effective outcome of
> "communication design is hard, let's just use TCP".

The point on using something simple is that it is NOT the job of the 
DLEP protocol to solve the transport problems. If you have a special 
link between radio and router, just use a better transport protocol. 
DLEP should not care as long as the transport is reliable.

Building our own reliable, low-delay, thinks-about-everything (and maybe 
reinvent-the wheel) style transport into DLEP doesn't sound like a good 
idea.

If we want to use UDP, going the "lets use Stop-and-wait" might be the 
only option that does not greatly increase the complexity of the protocol.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Aug 2013 08:48:48 +0200

Op 9 aug. 2013, om 08:22 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> The point on using something simple is that it is NOT the job of the DLEP protocol to solve the transport problems. If you have a special link between radio and router, just use a better transport protocol. DLEP should not care as long as the transport is reliable.
> 
> Building our own reliable, low-delay, thinks-about-everything (and maybe reinvent-the wheel) style transport into DLEP doesn't sound like a good idea.
Exactly.

Main objective is getting a document out as fast as we can, and more important, get the protocol running out in the wild. Simple and straightforward is important here.

We shortly discussed SCTP. Could be a better choice as it may somewhat better support what we need. On the other hand, UDP and TCP stacks are everywhere and these fit.

> 
> If we want to use UDP, going the "lets use Stop-and-wait" might be the only option that does not greatly increase the complexity of the protocol.
Yes.
TCP can easily beat such. Less work, better performance. That's why we decided to go for TCP.

Teco

---

From: <[email-masked]>
Date: Fri, 9 Aug 2013 09:52:40 +0100

Getting a document out fast?

RFC4938 was published in June 2007.

We have designed and suggested a number of different simple and straightforward non-PPPoE approaches to this problem, detailed at the url below.

But NOW you want a document, fast? After over six years?

Lloyd Wood

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Teco Boot [[email-masked]]
Sent: 09 August 2013 07:48
To: [email-masked] List
Subject: Re: [manet] DLEP and TCP

Exactly.

Yes.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Aug 2013 11:04:34 +0200

> RFC4938 was published in June 2007.

So what? RFC4938 does not fit adhoc radio networks. In fact I know quite 
a few organizations who got very frustrated about it.

> We have designed and suggested a number of different simple and
> straightforward non-PPPoE approaches to this problem, detailed at the
> url below.

It seems you never tried to push them towards a RFC.

> But NOW you want a document, fast? After over six years?

After less than 3 years... DLEP (version 00) started at the end of 2010.

The work on RFC4938 started in 2004 and ended in 2007... which was 
obsoleted by RFC5578 in 2010.

Its still a tool that doesn't fit the problem we are working on in DLEP.

I think parts of DLEP could be seen as "lessons learned" from RFC4938 
and RFC5578.

Henning Rogge

---

From: <[email-masked]>
Date: Fri, 9 Aug 2013 10:40:13 +0100

That organisations became frustrated with RFC4938 does not surprise me, despite the political weight behind it.

DLEP adapted the PPPOE mechanisms and metrics as much as possible; it is the heir to that, and the chosen design, again with poliical weight. If you don't like it, throw it out. But political weight will make DLEP the chosen solution, whatever DLEP looks like. Feel free to suggest alternatives, and to test that political weight. Good luck!

Lloyd Wood

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Henning Rogge [[email-masked]]
Sent: 09 August 2013 10:04
To: [email-masked]
Subject: Re: [manet] DLEP and TCP

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Aug 2013 12:25:33 +0200

On 08/09/2013 11:40 AM, [email-masked] wrote:
> That organisations became frustrated with RFC4938 does not surprise
> me, despite the political weight behind it.
>
> DLEP adapted the PPPOE mechanisms

One of the best things DLEP does is to get RID OF the PPPoE mechanisms. 
Its neither end-to-end nor point-to-point.

 > and metrics as much as possible;

I disagree again. DLEP is similar but we spent quite a bit of discussion 
and work to fix a lot of issues with the metrics of RFC4938.

 > it is the heir to that, and the chosen design, again with poliical
> weight. If you don't like it, throw it out. But political weight will
> make DLEP the chosen solution, whatever DLEP looks like. Feel free to
> suggest alternatives, and to test that political weight. Good luck!

I think DLEP already was pushed away from the RFC4938-like encoding and 
protocol to a much better solution. Which is enough evidence for me that 
there is quite a bit of working group input moving the protocol.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 9 Aug 2013 14:31:05 +0000

OK, so we've still got Martin's concerns in front of us: 

(Inclusion from [email-masked]):
I'm a little concerned about flow control messages working over TCP. We're looking at an application that emphasizes low latency and are trying to operate with very small queues at the radio; to do this without creating idle time at the radio requires tight bounds on when credit grants get to the router.

(end of inclusion)

As I've mentioned on several occasions, I'm adamantly opposed to removing the flow control from the "base" DLEP spec. Removing flow control from the base spec doesn't "fix" the problem, either - at least to me, that's just "kicking the can down the road". There's a valid concern here that TCP algorithms, and/or congestion on the router/radio link, could really muck things up. 

Alternatives?

Regards,
Stan
 
On Aug 9, 2013, at 6:25 AM, Henning Rogge <[email-masked]> wrote:

> One of the best things DLEP does is to get RID OF the PPPoE mechanisms. Its neither end-to-end nor point-to-point.
> 
> I disagree again. DLEP is similar but we spent quite a bit of discussion and work to fix a lot of issues with the metrics of RFC4938.
> 
> I think DLEP already was pushed away from the RFC4938-like encoding and protocol to a much better solution. Which is enough evidence for me that there is quite a bit of working group input moving the protocol.
> 
> Henning Rogge
> 
> --

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Aug 2013 16:44:13 +0200

> As I've mentioned on several occasions, I'm adamantly opposed to removing the flow control from the "base" DLEP spec. Removing flow control from the base spec doesn't "fix" the problem, either - at…

Would DLEP flow control work on a congested router/radio link with
UDP? I am not sure about this.

As soon as we get a delay or even packet loss on this link, we will
get very strange effects anyways.

In addition to this I don't think we could get much congestion if the
router is doing DLEP based flow control, as long as the router/radio
link is faster than the radio.

Henning Rogge

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

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Aug 2013 16:46:07 +0200

Stan,

How would it work better with UDP, especially in those cases where TCP introduces some jitter?
Before this is made clear, my concerns are on UDP, not TCP.

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Aug 2013 17:00:57 +0200

Just took few more minutes to verify what would happen with DLEP flow control on top of UDP, with "congestion on the router/radio link" or "occasional loss-related delays".
More concerns on using UDP...

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 9 Aug 2013 15:26:03 +0000

Teco, 

On Aug 9, 2013, at 11:00 AM, Teco Boot <[email-masked]> wrote:

> More concerns on using UDP…
> 

Can you elaborate? For example, what did you do to verify, and what are the additional concerns? To be honest, I don't really understand your statement "How would it work better with UDP, especially in those cases where TCP intrudes some jitter?" I think TCP-induced jitter is one of the problems. With UDP, the packet goes. Maybe it gets dropped, and the protocol has to account for that, but it goes. It doesn't get buffered for some "unknown to the application" amount of time. 

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 9 Aug 2013 15:36:30 +0000

" Main objective is getting a document out as fast as we can"

Don't let the IESG hear you say that, that's not the accepted main objective creating RFCs. Correctness is important (or even dominant).

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: 09 August 2013 07:49
To: [email-masked] List
Subject: Re: [manet] DLEP and TCP

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Exactly.

Yes.

Teco

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Aug 2013 18:07:05 +0200

> Don't let the IESG hear you say that, that's not the accepted main objective creating RFCs. Correctness is important (or even dominant).
I cannot see a contradiction.

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Aug 2013 18:17:23 +0200

Op 9 aug. 2013, om 17:26 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> Can you elaborate? For example, what did you do to verify, and what are the additional concerns? To be honest, I don't really understand your statement "How would it work better with UDP, especially in those cases where TCP intrudes some jitter?"
It is a question.

> I think TCP-induced jitter is one of the problems. With UDP, the packet goes. Maybe it gets dropped, and the protocol has to account for that, but it goes. It doesn't get buffered for some "unknown to the application" amount of time. 
I don't get why a TCP packet would not go.
If there is congestion, both packets will have queuing delays. With large congestion, UDP will blow up the link. But as we can easily agree on, there shouldn't be congestion. It is a MUST.
If there is loss, TCP recovers (rather quickly because very small RTT). If you want to beat TCP in your app, go for it. It wouldn't make the draft less pages, not to mention lines of code. On the end, I wonder if you really outperform TCP. Probably you copied TCP (Nagle turned off).

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Fri, 9 Aug 2013 20:24:58 +0000

I agree that UDP, in itself, is going to have its own set of problems when a message is lost, whether of a flow control type or not. If flow control is poorly designed I can see cases where flow dries up because the router has zero credits and the first credit award is lost, so we'll have to develop mechanisms to avoid that case.

My concern is the process afterwards. In UDP the next flow control packet will not incur any delay except for whatever it takes for other queued messages and data to go out over the Ethernet interface. In the case of TCP, after the lost message times out we'll be in slow start and later flow control packets will have to wait for ACKs to come back.

As for the Nagle algorithm, I agree that if we specify that DLEP must be invoked with the TCP_NODELAY option we'll be OK.

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: Friday, August 09, 2013 7:46 AM
To: Stan Ratliff
Cc: <[email-masked]>
Subject: Re: [manet] DLEP and TCP

Stan,

Teco

Op 9 aug. 2013, om 16:31 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

>>> weight. If you don't like it, throw it out. But political weight
>>> will make DLEP the chosen solution, whatever DLEP looks like. Feel
>>> free to suggest alternatives, and to test that political weight. Good luck!
>>

---

From: <[email-masked]>
Date: Sat, 10 Aug 2013 07:25:27 +0100

Sorry, I should have phrased that for clarity as ''adapted the mechanisms using PPPoE" - including the 0-100 percentage TLVs (because representing 0-255 in an octet would be difficult.)

0-100, TLVs, metrics inherited from the space the PPPoE solution was designed for - DLEP looks remarkably similar to RFC5578 and RFC4938 to me. A general solution? I have doubts.

Lloyd Wood

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Henning Rogge [[email-masked]]
Sent: 09 August 2013 11:25
To: [email-masked]
Subject: Re: [manet] DLEP and TCP

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sat, 10 Aug 2013 09:07:58 +0200

> I agree that UDP, in itself, is going to have its own set of problems when a message is lost, whether of a flow control type or not. If flow control is poorly designed I can see cases where flow dr…
Yes.
My question is: does it outperform TCP and is the effort useful?

> My concern is the process afterwards. In UDP the next flow control packet will not incur any delay except for whatever it takes for other queued messages and data to go out over the Ethernet interf…
My assumption is that the router-radio link is not congested and even a one MTU receive window doesn't introduce much of a problem.
Again, router-radio link is high speed (e.g. >> 4 times RF link) and RTT is almost zero (microseconds, not milliseconds).

Remember: I don't want to push TCP that hard. I just say: use TCP or work hard to get it right. 
Maybe check SCTP. It may better for but is less widely deployed.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sat, 10 Aug 2013 09:26:56 +0200

> Sorry, I should have phrased that for clarity as ''adapted the mechanisms using PPPoE" - including the 0-100 percentage TLVs (because representing 0-255 in an octet would be difficult.)

The "Relative Link Quality" metric is really a legacy metric. Many
people don't like it but we keep it there to keep everyone happy. And
even then we had to fix the mistake of RFC4938 to declare a link that
cannot be measured always as "perfect", which can be the death of
heterogeneous networks.

> TLVs, metrics inherited from the space the PPPoE solution was designed for - DLEP looks remarkably similar to RFC5578 and RFC4938 to me. A general solution? I have doubts.

TLVs? I am sorry, but if you think that RFC5578 is the reason for
using TLVs in a protocol then I think you have a little bit tunnel
vision.

About the list of metrics, that is the whole reason why we have
started the "DLEP design team"... to cleanup the list of metrics and
make sure we got them well defined.

I think the current plan is to get the list of metrics in the DLEP
core spec as small as possible to a minimum set and then write one or
two additional Drafts about statistical data and physical-/linklayer
metrics.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Sat, 10 Aug 2013 09:31:57 +0200

> As for the Nagle algorithm, I agree that if we specify that DLEP must be invoked with the TCP_NODELAY option we'll be OK.

I think you are right, we should think about the TCP/UDP problem.

But the first question we should ask is "is it a reasonable assumption
that the radio/router link becomes congested".

I think the answer is no. Anyone building a IP capable radio with DLEP
support that has an air-interface as fast as the ethernet connection
should check his or her priorities. 100 MBit and even Gigabit ethernet
is really cheap today, which should solve the congestion problem for
most radios. If you build a radio which has a faster air interface
than its ethernet connection to the router, you will have lost
anyways.

Maybe I am wrong, but I would like to hear about the scenario where
the ethernet link will be congested on a radio-router connection which
use DLEP flow-control.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 01:36:38 +0200

> Of we build flow control over UDP, how to handle loss?

By using explicit application-layer acknowledgments, as is done in
OSPF, EIGRP, uTP and many more protocols.

> Why would it perform better than TCP?

Because upon a loss event, you send new data, and decrease the rate of
updates, rather than queueing ever increasing amounts of now obsolete
data.  (You can actually be smarter than that -- have a look at mosh.)

> Doesn't the push option enforce direct delivery?

No.  It's a NOP.

(It was originally intended to disable queueing in mainframes'
I/O coprocessors.)

> Nagle can be turned off, I think.

Yes.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 01:40:01 +0200

> link between radio and router, just use a better transport
> protocol. DLEP should not care as long as the transport is reliable.

I think that's a good point.  It would mean that the discovery
subprotocol should be powerful enough to express something like "I can
speak DLEP/TCP on port 1234, but also DLEP/DCCP on port 4567 and
DLEP/UDP-based-reliable-protocol-of-the-day over port 7890".

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 08:51:59 +0200

> data.  (You can actually be smarter than that -- have a look at mosh.)

Does this even happen on a non-saturated link AND a non-saturated 
TCP-stream for DLEP?

I mean, we are talking about sending kilobytes, maybe dozens of 
kilobytes per second on a link that still has capacity for megabytes per 
second.

Even if we have a packet loss, which will trigger a congestion 
avoidance, wouldn't fast retransmit and fast recovery clean the buffer 
very quickly again? We are talking about a situation where there 
outgoing buffer for the connection is nearly always empty because the 
linklayer gets the packets away much faster than we produce them.

>> Nagle can be turned off, I think.

Yes, mentioning to turn of Nagle sounds like a good idea.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 08:53:54 +0200

On 08/09/2013 04:31 PM, Stan Ratliff (sratliff) wrote:
> (Inclusion from [email-masked]): I'm a little concerned about
> flow control messages working over TCP. We're looking at an
> application that emphasizes low latency and are trying to operate
> with very small queues at the radio; to do this without creating idle
> time at the radio requires tight bounds on when credit grants get to
> the router.
>
> In general a non-greedy application (like DLEP's control plane)
> running TCP over an Ethernet connection should not trigger many
> packet losses, but I'm concerned about both occasional loss-related
> delays, and the Nagle algorithm raising the bound on control message
> delivery time.

I still would like to hear how this "heavy delay" would happen on a 
non-saturated link which is magnitudes faster than the amount of traffic 
we want to send.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 08:57:50 +0200

> DLEP/UDP-based-reliable-protocol-of-the-day over port 7890".

We could add this in an extension draft.

We make TCP mandatory for every DLEP implementation (both radio and 
router), but create a new TLV (in another draft, not in the core 
document) where a radio announce "you can also use transport protocol X 
on port Y". The router then can decide what to use to contact the radio.

This would gives us an upgrade-path for special cases without bloating 
the core document.

I am totally against NOT having a mandatory transport protocol, because 
this will quickly lead to DLEP radios and routers that are standard 
compliant and incompatible with each other.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 12 Aug 2013 08:39:45 +0000

I'm entirely with Henning on this one.  The core DLEP spec should specify something along the lines of:

* A DLEP implementation MUST support TCP if the radio to router interface uses IP.

* A DLEP implementation using TCP SHOULD disable Nagle.

* A DLEP implementation MAY advertise an alternative/improved transport protocols (in some non-core defined extension TBD) and these transport protocols MUST be reliable (do we need to define 'reliable' or is there an RFC that covers our requirements?).

I understand that some people may have concerns over congestion and flow-control over the router<->radio link, but in the common case it is expected that that link will be faster than the radio<->radio interface by enough to negate the concerns.

If the radio<->router link becomes an issue, then an alternative transport MAY be used by supporting equipment, but it remains a problem for high-speed device implementers.

Even if the radio<->radio link characteristics begin to approach the characteristics of the radio<->radio link, there is nothing to stop the radio and/or router reducing the frequency of DLEP control messages to prevent interference with the data-flow over the radio<->radio link.

It is not expected with DLEP that protocol messages are exchanged so rapidly that a 10M Ethernet link is flooded, and most (all?) radio and router manufacturers already have embedded controllers on-board that can support faster than 10M on copper. We are not discussing a 9600 baud link between radio and router.

Rick Taylor

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henning Rogge
> Sent: 12 August 2013 07:58
> To: Juliusz Chroboczek
> Cc: [email-masked]

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 10:56:56 +0200

> * A DLEP implementation MAY advertise an alternative/improved
>   transport protocols (in some non-core defined extension TBD) and
>   these transport protocols MUST be reliable

I'm not sure about that.

One of the reasons to use a protocol different from TCP is to discard
obsolete data upon a loss event and send newer data instead.
A reliable protocol cannot do that.

(The other -- and main -- reason is to reduce the sending rate upon congestion.)

A good description of one such protocol is a paper that I most warmly
recommend,

  Keith Winstein, "Mosh, an interactive remote shell for mobile clients",
  USENIX 2012.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 11:03:33 +0200

> A reliable protocol cannot do that.

If the transport is allowed to drop packets, we are back at step A. 
Suddenly we need all the acknowledgement/retransmission mechanism in DLEP.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 12 Aug 2013 10:17:19 +0000

> A reliable protocol cannot do that.

Dropping obsolete packets is not currently under consideration with DLEP.  What is an obsolete packet?  Do you want that specified with each packet type?  Are you suggesting we split the protocol into reliable and partial-reliable messages?

I want to move away from this model, at least in the core spec.  If a vendor wishes to implement a second transport built around SCTP with partial-reliability extensions and carefully specify (in an external document) which packets are always delivered and which are 'replaced' under congestion with newer information, then that is their business, but they MUST still support TCP/IP.

> (The other -- and main -- reason is to reduce the sending rate upon

Sending rate congestion (as previously stated) is not expected under 'usual' circumstances.  For the unusual case, see above.

>   Keith Winstein, "Mosh, an interactive remote shell for mobile clients",

I'll have a look at some point, but remember: the router is not 'mobile' in relation to its local radio.  This is not a 'remote' relationship.  There will always be a short cable at most between the devices.

Rick Taylor

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 12 Aug 2013 11:25:34 +0000

If your main objective is getting a document out fast, you may be prepared to sacrifice some quality, as that's now a secondary objective. That's not the tradeoff the IESG will make in my experience.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 09 August 2013 17:07
To: Dearlove, Christopher (UK)
Cc: [email-masked] List
Subject: Re: [manet] DLEP and TCP

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 12 Aug 2013 12:12:47 +0000

I believe the intention is to make rapid progress towards a document of the usual high standard demanded by the IESG.

Is that sufficiently politically correct?

Rick Taylor

> Dearlove, Christopher (UK)
> Sent: 12 August 2013 12:26
> To: Teco Boot
> Cc: [email-masked] List
> If your main objective is getting a document out fast, you may be prepared
> to sacrifice some quality, as that's now a secondary objective. That's not
> the tradeoff the IESG will make in my experience.
>
> --
> Christopher Dearlove
> Op 9 aug. 2013, om 17:36 heeft "Dearlove, Christopher (UK)"
> <[email-masked]> het volgende geschreven:
>
> > Don't let the IESG hear you say that, that's not the accepted main
> objective creating RFCs. Correctness is important (or even dominant).
> > Op 9 aug. 2013, om 08:22 heeft Henning Rogge
> <[email-masked]> het volgende geschreven:
> >
> DLEP protocol to solve the transport problems. If you have a special link
> between radio and router, just use a better transport protocol. DLEP
> should not care as long as the transport is reliable.
> >>
> >> Building our own reliable, low-delay, thinks-about-everything (and
> maybe reinvent-the wheel) style transport into DLEP doesn't sound like a
> good idea.
> > Exactly.
> >
> > Main objective is getting a document out as fast as we can, and more
> important, get the protocol running out in the wild. Simple and
> straightforward is important here.
> >
> > We shortly discussed SCTP. Could be a better choice as it may somewhat
> better support what we need. On the other hand, UDP and TCP stacks are
> everywhere and these fit.
> >
> >>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 12 Aug 2013 14:21:52 +0000

Chris, 

I think we're all a bit frustrated with the lack of progress, and it's time to kick the intensity level up a notch or two. No one that I know of is ready to sacrifice correctness on the altar of expediency - we just want it done. 

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 12 Aug 2013 14:36:40 +0000

On Aug 12, 2013, at 2:51 AM, Henning Rogge <[email-masked]> wrote:

> Does this even happen on a non-saturated link AND a non-saturated TCP-stream for DLEP?
> 
> I mean, we are talking about sending kilobytes, maybe dozens of kilobytes per second on a link that still has capacity for megabytes per second.

But, at this point, we're somewhat designing the protocol with a network implementation in mind, aren't we? I mean, just flipping back through the recent email thread, I've seen a couple of assumptions stated: 
1. The link between router and radio is *always* local (e.g. the radio is the next hop), and 
2. The link between router and radio will *always* be faster (some have said 'orders of magnitude faster') than the RF link. 

If the consensus of the WG is that those assumptions will always hold, then OK. Perhaps I should add them to the assumptions section of the draft. To be honest, I don't have any implementations in mind that would violate those 2 assumptions; but I don't know if that's the case for all potential implementers of DLEP. So, it makes me stop and think...

Regards,
Stan

> 
> Even if we have a packet loss, which will trigger a congestion avoidance, wouldn't fast retransmit and fast recovery clean the buffer very quickly again? We are talking about a situation where there outgoing buffer for the connection is nearly always empty because the linklayer gets the packets away much faster than we produce them.
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 16:47:06 +0200

> I think we're all a bit frustrated with the lack of progress, and it's time to kick the intensity level up a notch or two. No one that I know of is ready to sacrifice correctness on the altar of ex…

Yes,

thats also one reason why we started the "design team", to do some
effective research on the metrics for DLEP in parallel so we can
create a comprehensive list before we run it through the Manet WG
again. Discussing the transport part here in the group while also
working on a list of metrics should speed up things (hopefully) a lot.

Henning Rogge

---

From: Brian Adamson <[email-masked]>
Date: Mon, 12 Aug 2013 11:50:27 -0400

I mostly concur with the recommendation here(e.g. strive to let DLEP work on top of different physical/logical media) , but think the DLEP specification should clearly indicate what its requirements for the underlying transport & interconnect are in terms of:

1) ordered message delivery
2) reliability
3) adaptive (e.g. dynamic congestion control) or preset transfer rate, or both
4) flow control 
5) Any DLEP transport session parameters that need to be established
6) Automated discovery (e.g. similar to what PPPoE can do but using mDNS, uPNP or something?)

There will likely be different message bus technologies that might be suitable for handling DLEP requirements.  

The one concern here is to do this in a way that doesn't defeat interoperability.  I.e., some minimal common mechanism should be mandated.

Brian Adamson
[email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 18:10:54 +0200

> 1. The link between router and radio is *always* local (e.g. the radio is the next hop), and

If DLEP use linklocal multicast for discovery it will not work for
more than one (IP) hop anyways. Also sending bridged traffic over
multiple IP hops will require some kind of tunnel, which should be out
of scope for the DLEP core spec.

Using multiple layer-2 hops might work, as long as you keep the total
datarate in mind. Connecting multiple slow radios over a single
gigabit ethernet switch to the router might work, but it would still
need either a manageable switch (VLANs to select to outgoing ports) or
some crazy trickery with the traffic.

> 2. The link between router and radio will *always* be faster (some have said 'orders of magnitude faster') than the RF link.

I would say yes.

If someone wants to violate this 2nd assumption, then I can see a way
to still make this work:
1) use a dedicated point to point ethernet link
2) use prioritization and traffic shaping to guarantee there is always
capacity left for the DLEP traffic.

> If the consensus of the WG is that those assumptions will always hold, then OK. Perhaps I should add them to the assumptions section of the draft. To be honest, I don't have any implementations in…

I think they are both reasonable. Especially if you plan to use
flow-control with DLEP.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 18:50:09 +0200

> 1. The link between router and radio is *always* local...
> 2. The link between router and radio will *always* be faster...

Assuming these assumptions always hold in normal usage of DLEP -- is
it acceptable for DLEP to collapse when they do not?  Should it be
able to recover in a timely manner when the conditions are met once again?

-- Juliusz

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 12 Aug 2013 17:59:22 +0000

> able to recover in a timely manner when the conditions are met once again?

A couple of observations. First, the obvious answer to your questions are "no" and "yes", respectively. 

Second, I'm not sure we've discussed a case yet where DLEP would "collapse"… but perhaps we're working off of different interpretations of that term. What I can see is a case where, if the physical link from router to radio is ever outpaced by the wireless link, *or* in the case where the router-radio link is sporadically congested, then the notion of flow-controlling the radio via DLEP is problematic (due to potential packet delays within the transport mechanism, or DLEP flow-control packet drops). Outside of the (optional) flow control mechanism, I'm not seeing a case where even sporadic congestion on the router-radio link would cause an issue I'd define as a "collapse" - the worst case I can see is the dropping/re-transmission of a "Neighbor Down" packet, which could cause traffic black-holing for the duration of the TCP retransmission cycle. However, the same issue would exist using UDP as a transport: if the "Neighbor Down" is dropped, traffic could get black-holed unless/until the sender (the radio) (a) determines that the Neighbor Down got dropped, and (b) successfully retransmits it. In either case, the problem would persist until either the DLEP implementation (or the transport) successfully transmits the packet, *or* the routing protocol's "Dead Timer" fires.  Therefore, you could argue that the routing protocol's Dead Timer effective acts as a "backstop" for this occurrence. 

Is there a  case I'm missing?

Regards,
Stan

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 21:08:46 +0200

>> Assuming these assumptions always hold in normal usage of DLEP --
>> is it acceptable for DLEP to collapse when they do not?  Should it
>> be able to recover in a timely manner when the conditions are met
>> once again?

> A couple of observations. First, the obvious answer to your
> questions are "no" and "yes", respectively.

Yeah, they were rigged ;-)

> Second, I'm not sure we've discussed a case yet where DLEP would "collapse"
[...]
> Is there a  case I'm missing?

TCP will buffer DLEP updates even when the router-radio link is
hopelessly congested or down.  When the link is operational again, new
updates will be sent only after TCP times out (which can take up to 30
seconds, if memory serves) and the buffers drain (which can take an
arbitrarily large amount of time unless the amount of buffering is
carefully controlled).  We're probably speaking of a worst case of at
least a couple of minutes in a naive implementation.

I'm pretty sure that can be reduced to well under one minute (without
kernel changes) by carefully controlling the size of the TCP buffers
with non-blocking writes, using application-layer keepalives with
short timeouts, and probably other tricks.  Is doing that properly any
easier than implementing a well-designed protocol layered over UDP?
I don't know, since, while I have a fair amount of experience with
implementing stuff over UDP, I don't have any with implementing
real-time protocols over TCP.

-- Juliusz

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 12 Aug 2013 19:32:11 +0000

> Yeah, they were rigged ;-)

Yes. To the point that my initial reaction was to consider your email as not serious, and therefore, to not respond.

> least a couple of minutes in a naive implementation.

A "couple of minutes" bumps into the routing protocol's Dead Timer (even with a naive implementation of the Dead Timer), so… 

Keeping the application-level Heartbeat message in the specification would allow an implementation to detect the problem faster. It might seem like overkill at first blush, but I think there's some merit to keep it, even over TCP. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 13 Aug 2013 07:06:56 +0200

> Keeping the application-level Heartbeat message in the specification would allow an implementation to detect the problem faster. It might seem like overkill at first blush, but I think there's some…

Sure we keep the heartbeats. I would like to see a fresh TCP connection in seconds rather than minutes. The new connection will reset state machines, so neighbors go down and up.

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 13 Aug 2013 08:24:16 +0000

Brian, I tried to start a breakdown of requirements, see my email to the list entitled "DLEP message classification".

I agree that there are situations where the radio and router may be connected by a non-IP medium, e.g. a PCI bus.

Rick Taylor

________________________________
From: Brian Adamson [mailto:[email-masked]]
Sent: 12 August 2013 16:50
To: Taylor, Rick
Cc: Henning Rogge; Juliusz Chroboczek; [email-masked]
Subject: Re: [manet] DLEP and TCP

Brian Adamson
[email-masked]<mailto:[email-masked]>

Rick Taylor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Henning Rogge
Sent: 12 August 2013 07:58
To: Juliusz Chroboczek
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] DLEP and TCP

Henning Rogge

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 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 13 Aug 2013 08:25:43 +0000

+1 for heartbeats remaining.  BGP shows that they are still needed even when running over TCP.

Rick Taylor

> Teco Boot
> Sent: 13 August 2013 06:07
> To: Stan Ratliff (sratliff)
> Cc: <[email-masked]>; Juliusz Chroboczek
> Op 12 aug. 2013, om 21:32 heeft "Stan Ratliff (sratliff)"
> <[email-masked]> het volgende geschreven:
>
> >
> > Yes. To the point that my initial reaction was to consider your email as
> not serious, and therefore, to not respond.
> >
> >>
> > A "couple of minutes" bumps into the routing protocol's Dead Timer (even
> with a naive implementation of the Dead Timer), so...
> >
> > Keeping the application-level Heartbeat message in the specification
> would allow an implementation to detect the problem faster. It might seem
> like overkill at first blush, but I think there's some merit to keep it,
> even over TCP.
>
> Sure we keep the heartbeats. I would like to see a fresh TCP connection in
> seconds rather than minutes. The new connection will reset state machines,
> so neighbors go down and up.
>
> Teco
>
> >
> > Stan
> >
> >>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 13 Aug 2013 08:33:33 +0000

> some crazy trickery with the traffic.

I was working under the assumption that the radio and router were *always* local and in a one-to-one relationship.  As stated before, discovery becomes extremely complex with one-to-many radios to routers and switches.  Also, describing neighbours by their L2 address becomes 'unusual' in a one-to-many case.

I would recommend staying away from the complex switched case, and specifying something like 'a logical 1-hop connection between radio and router is required'.

Rick Taylor

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Aug 2013 09:37:54 +0000

Sooner or later, someone is going to suggest replacing the ethernet cable between the two by a wireless link, probably based on some version of 802.11. Maybe not in the sorts of networks some of us are interested in, but in some networks.

(That's not meant to be an argument for or against any specific proposal, just something to consider.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Taylor, Rick
Sent: 13 August 2013 09:34
To: Henning Rogge; Stan Ratliff (sratliff)
Cc: <[email-masked]>
Subject: Re: [manet] DLEP and TCP

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 14 Aug 2013 12:27:22 +0200

On 08/14/2013 11:37 AM, Dearlove, Christopher (UK) wrote:
> Sooner or later, someone is going to suggest replacing the ethernet
> cable between the two by a wireless link, probably based on some
> version of 802.11. Maybe not in the sorts of networks some of us are
> interested in, but in some networks.

If this happens we can suggest they this person creates a draft with an 
appropriate transport protocol for DLEP.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Aug 2013 10:46:32 +0000

The person who does this probably isn't even going to know DLEP exists, let alone consider submitting Internet Drafts. They'll just replace an ethernet cable.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 14 August 2013 11:27
To: [email-masked]
Subject: Re: [manet] DLEP and TCP

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Aug 2013 12:47:05 +0200

Op 14 aug. 2013, om 12:27 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> If this happens we can suggest they this person creates a draft with an appropriate transport protocol for DLEP.

I wonder if this is needed. As long as the peer RF link has enough capacity for DLEP, it is OK. Also, a low rate wired link could be a bottleneck (USB1.1 to 802.11ac radio). Or an ethernet bridge with low rate wired links (which I use), for example to connect a satcom terminal on somewhat longer distance with a router (I don't do that right now).

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 14 Aug 2013 14:15:08 +0000

As long as we're (still) talking about low-rate router-to-radio links, and DLEP…. 

What if I take a router, stick a cable into a FastEthernet port, and run the other end to a MIMO radio? At least in theory, methinks the RF link is now faster than the Ethernet cable…

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 14 Aug 2013 16:41:06 +0200

> What if I take a router, stick a cable into a FastEthernet port, and run the other end to a MIMO radio? At least in theory, methinks the RF link is now faster than the Ethernet cable…

yes, it would be. But you could not use the full capacity of the RF
link anymore because you added an artificial bottleneck.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 14 Aug 2013 14:47:00 +0000

That's absolutely true for outbound traffic. However, the RF could be maximally used for inbound traffic, thus creating the congested router-to-radio link we've been theorizing on…

My point is that overloading the router-to-radio link isn't as hard as I initially thought - in fact, it's pretty straightforward...

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 14 Aug 2013 16:49:55 +0200

As long as the radio prioritize the DLEP traffic on the Ethernet link
this might still be okay. Not perfect, but not a catastrophe either.

Maybe we should add this into the suggestions/best-practice part of the draft?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Aug 2013 17:09:53 +0200

The bloody user traffic....

Back to starting point: DLEP router radio link should (must?) have higher capacity than RF link. It doesn't matter if it is ethernet, 802.11-something or whatever. My suggested rule of thumb: 4 times maximum rate on RF. Router would know MDR and DLEP interface, so it could log a message if conditions are not as specified.

Now what would happen when there is (temporary) congestion on the router radio link. I would say that is one of the unimportant discussions. And that most of DLEP is not really affected. Transfer of link metrics can tolerate some delay, I think. For flow control, the effect might be unused idle time on the RF link. OK, not perfect. But nothing breaks.

Having QoS on the router to radio link for DLEP and DLEP flow control because the radio doesn't have QoS functions? I don't go in that direction. 

Teco