Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #15404

Re: UDP timers

Show all headers | View raw

On 2014-01-03, Don Y <this@isnotme.com> wrote:
> Hi,
>
> I've been discussing this in another forum and we haven't (yet!)
> come up with any generic approaches that can be bent to the task.
> So, I figured it was worth exploring, here...
>

That's because there isn't a generic approach which I can see. Different
response requirements and network bandwidth/costs (and types of costs)
require different solutions. Read on for some of my thoughts.

> I've got some UDP-based protocols that try to be really lean
> (hence the avoidance of TCP!).  They also must provide certain
> timeliness guarantees for the mechanisms that rely on them.
> And, reliable delivery (heh heh heh).
>

So you don't want TCP, but you want 80% of what TCP provides ? :-)

You know what they say about those who fail to understand TCP... :-)

You have also left out some details; you have not provided any details
on expected transmission rates or required confirmation-of-receipt
response times.

What is the nature of the network ? Directly connected Ethernet/wireless,
some cost per packet communications network, or a mobile phone data
network (or something else) ?

How many nodes in this network ?

Is this a one-way data flow (from remote device to some host) or a
bi-directional data flow ?

> Deployed, the network configuration is either known a priori
> or network discovery *at* deployment suffices (thereafter,
> networks are *very* static!).  Networks are intended to be
> private and contain only "well behaved" devices.
>

...until a device fails and starts pouring junk onto the network or until
some bright spark decides to plug something new and unexpected into your
network...

> I currently use RTT estimates based on information that the
> device, AS AN INTEGRATED ENTITY, can gleam from the *set* of
> protocols running thereon. (This lets me avoid adding extra
> traffic as "overhead" -- low information content per octet).
> I.e., instead of explicit acknowledgements (which add overhead),
> the acknowledgements are *inferred* from other observable
> behaviors in the device as a whole.
>

Why do this ? Are you using a financial cost per packet communications
network or some very low data rate network ?

I also don't fully understand fully how this avoids acknowledgements.
A specific example is required here I think. :-)

However, for whatever specific subset of problem domains this approach
may work for, it's not going to be scalable to the generic approach you
are looking for.

It also seems fragile even for the problem domains for which it can be
made to appear to work.

> While I can get a rather precise metric for the temporal costs
> of the *fabric*, I'm having a harder time trying to factor in
> the variance in the processing times on the (remote) node
> without artificially tightening its deadline constraints.
>
> Specifically, I'm trying to (dynamically) maintain the functional
> equivalent of the RTO at the minimum level that *just* catches
> a lost datagram without waiting wastefully too long *or*
> "correcting/recovering" prematurely.  The algorithms used in
> commodity stacks tend to be very naive in their expectations
> (of necessity!) so you don't get a finely tuned response.  There,
> the cost of a dropped packet is inconsequential.  I want to
> dynamically alter the deadline that invokes the "recovery
> handler" for these particular protocol instances -- not too soon
> (wasted effort as the "dropped" datagram may be arriving *as*
> the handler starts running!) nor too late (threatens performance).
>

So you don't want TCP, but you behave like TCP in that you only send
packets when you have something to transmit ?

However you do it, you still need some acknowledgement packet/signal back
from the other end because that's the only way you are going to know for
sure (at least in your desired generic solution) the packet was received.

If there's no cost involved in actually transmitting packets, then why
not simply transmit packets all the time, at a acceptable rate, in both
directions ?

The device's packet contents can tell the host if there's any data within
the packet and the packet header from the host can contain information
about the last packet received from the device. It also provides a
keep-alive capability so that if the packets stop flowing you know either
a node or the part of the network the node is connected through is down.

Of course the above only works if you are not paying a financial cost for
keeping the network up (either connect time or per packet/bandwidth charges)
and you are not using a really low bandwidth network.

I don't see anything in your current solution which gives you a keep-alive
capability (assuming data is not expected from the device at regular
intervals) but a specific example of your current solution in use may help
me understand that.

> I guess this boils down to filters to guesstimate runtimes of
> specific (remote!) tasks?
>

No, because you seem to still be thinking like TCP (in that you want to
respond to transmission of specific pieces of data from the device) even
though that's what you seem to be saying you don't want.

Of course, what you may _really_ mean is that you want everything TCP
gives you but without TCP's latency in the presence of packet loss.

Also, you talk about a generic solution but there's no way your approach
can scale to a generic set of task workloads. You may have a specific
subset of tasks for which your approach is suitable but that's not the
generic solution you are seeking.

If you want a generic solution then go with some form of ACK packet. If
latency is a concern when dealing with packet loss, and if your network is
suitable, then just transmit on a regular basis, even if you have nothing
to send or nothing new to acknowledge.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
[Note: email address not currently working as the system is physically moving]
Microsoft: Bringing you 1980s technology to a 21st century world

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

UDP timers Don Y <this@isnotme.com> - 2014-01-03 14:03 -0700
  Re: UDP timers Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-01-05 15:46 +0000
    Re: UDP timers Don Y <this@isnotme.com> - 2014-01-05 14:28 -0700
    Re: UDP timers Grant Edwards <invalid@invalid.invalid> - 2014-01-06 16:08 +0000

csiph-web