Subject: Applications assume bilateral connections?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Dec 2008 07:04:19 -0800

One of the topics that came up in the architectural debate is that a few folk made statements of the form that application developers assume that applications only engage in bilateral communications. In fact one person went so far that applications developers are not aware of the range of applications protocols. 

But more generally, some appear to have voiced the opinion that the IETF transport area only serves the IETF applications area, not the Internet application developer community which is many, many times the size of the IETF.

No examples were given of these non-application application protocols. So here is why there can only be bilateral communications at the application layer.

>From the point of view of an application there are only two significant classes of object:

1) Itself
2) Anything that is not itself

Every communication at the application layer, in every protocol that I am aware of boils down to a bilateral communication between those two groups. There are thus four possibilities

1) Application talking to itself, not as unusual as it might seem. I was once surprised to find that a DEC tape drive would not work unless RPC was turned on despite having a direct SCSI connection to the machine.

2) Inbound communication

3) Outbound communication

4) Communication that does not involve the application directly but may affect the application indirectly.

As far as an application is concerned, multicast is simply a communication with a service that is not itself. There may be one or a million hosts in a multicast session but the session itself is a single service. It is like being in an IRC chat room, there is one chat room, but many hosts.

If multicast protocols appear to require applications to have direct knowledge of an IP address, that is a layer violation. From my own point of view I am really skeptical about any protocol that requires state to be maintained in the Internet backbone to operate (as opposed to local state for optimization)

As it is however, the multicast protocols don't seem to be any different here. As far as the receivers are concerned they might as well be the only receiver in the entire world. As far as the source is concerned there is only the source and 'rest of world'.

Similar arguments may be applied to local broadcast.

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Dec 2008 10:43:43 -0500

--On Tuesday, 02 December, 2008 07:04 -0800 "Hallam-Baker,
Phillip" <[email-masked]> wrote:

> One of the topics that came up in the architectural debate is
> that a few folk made statements of the form that application
> developers assume that applications only engage in bilateral
> communications. In fact one person went so far that
> applications developers are not aware of the range of
> applications protocols. 
> 
> But more generally, some appear to have voiced the opinion
> that the IETF transport area only serves the IETF applications
> area, not the Internet application developer community which
> is many, many times the size of the IETF.
> 
> No examples were given of these non-application application
> protocols. So here is why there can only be bilateral
> communications at the application layer.
>...

Of course, there are a whole class of exceptions to this.  There
are applications that perform minimal-effort notification or
database update functions that do not particularly care if the
notification gets through (i.e., can accept some data loss in
the process).  I've worked on several such applications over the
years in which the consumer of the data needed only the most
recent values available and perhaps an indication of whether
recent data had been lost (easily accomplished with a simple
sequence number) or how recent the most recent available data
were (for which a time stamp is usually sufficient).

One set of examples for this involves remote sensors (sometimes
very remote, as in "in orbit") that are reporting on data that
are considered only statistically for other reasons.
Constructing, e.g., moving average models that can allow for
some missed data points is fairly straightforward and often
makes a lot more sense than trying to assure reliable
transmission or anything else that would require a bilateral
connection arrangement.  While it is outside my personal
experience, I'd assume that sensors that deliver snapshots from
high-data-volume, high-data-rate experiments in physics would
have much the same properties, with the quantity and arrival
rate of the data overwhelming any possibility of bilateral
handshaking and the probability of some data loss being much
more acceptable than a lower sample rate.

In some cases, the transmitter at the sensor just broadcasts the
data on a known channel, with no information (including either
names or addresses) about who is going to receive it or how it
is going to be received.   Certainly the receiver(s) need to
know the channel and the way in which the data are encoded, but
that doesn't involve the network in anything bilateral. 

Or perhaps you are using "bilateral" in a way that I don't
understand.
 
    john

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Dec 2008 08:52:59 -0800

It was not clear from the context of the argument what was being referred to. Seemed more likely that they were imaging something involving more parties than bilateral. It was one of those 'well people only disagree with me because they are ignorant of an area that I will specify so vaguely a to make it impossible to refute the claim' type shots.

As someone with significant experience of high bandwidth, high data rate physics experiments (My doctorate is on work I did on the ZEUS experiment at DESY in Hamburg), I would distinguish two classes of communication:

1) Sensor reading
2) Network communication

Sensor reading is physics, not network engineering. Once you get past the initial sensor the communications become bilateral pretty quickly. Flow control becomes more critical, not less when you have a system of that size. And you have to take account of the fact that you have more than one event in the pipeline at the same time. Flow control may only be a single bit but it is bilateral communication.

A unilateral communication is simply a bilateral communication where only one party has something interesting to say. I don't see how it could be imputed to create a need for applications to concern themselves with IP header contents or have any other architectural consequences.

As a former control engineer, I tend to consider any communication loop without feedback as being inherently broken. If a thing is worth saying then it is worth making sure that it is listened to. Sure there are communications media such as satellite that are inherently one-way. Such media require a completely different architectural approach if used alone.

>From the apps point of view I don't see why an application interface to a multicast stream should look any different from an application interface to a unicast stream. In fact any distinction is a fault in my view.

One of the limitations of TCP/IP for apps developers is that it requires applications to merge control and data into a single channel. A better applications interface would allow these to be separated (c.f. DIME, BEEP etc) so you have a data channel paired with a (possibly lossy, possibly unidirectional) data channel.

Then write a network stack that allows such a connection to be established and opportunistically make use of whatever network resources are available at each end.

The bigger limitation of the Internet is that it provides no mechanism for clients, servers and infrastructure to advertise what is supported. We are trapped in the same old TCP+UDP box. In fact the box is shrinking to port 80 + 443 and may well shrink to just 443.

If Google and Comcast both deploy such a technology, how do applications discover that it exists and make use of it? That is the architectural gap that needs to be filled and the one that we should be discussing. Solve that problem and the apps area can make use of new transport area innovation.

-----Original Message-----
From: John C Klensin [mailto:[email-masked]]
Sent: Tue 12/2/2008 10:43 AM
To: Hallam-Baker, Phillip; [email-masked]
Subject: Re: Applications assume bilateral connections?

 
    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Dec 2008 17:11:11 -0500

--On Tuesday, 02 December, 2008 08:52 -0800 "Hallam-Baker,
Phillip" <[email-masked]> wrote:

> It was not clear from the context of the argument what was
> being referred to. Seemed more likely that they were imaging
> something involving more parties than bilateral. It was one of
> those 'well people only disagree with me because they are
> ignorant of an area that I will specify so vaguely a to make
> it impossible to refute the claim' type shots.

Then why did you initiate this conversation thread rather than
not wasting your/our time on it?
 
> As someone with significant experience of high bandwidth, high
> data rate physics experiments (My doctorate is on work I did
> on the ZEUS experiment at DESY in Hamburg),

That is why I mentioned that example.

> I would
> distinguish two classes of communication:
> 
> 1) Sensor reading
> 2) Network communication
> 
> Sensor reading is physics, not network engineering. Once you
> get past the initial sensor the communications become
> bilateral pretty quickly. Flow control becomes more critical,
> not less when you have a system of that size. And you have to
> take account of the fact that you have more than one event in
> the pipeline at the same time. Flow control may only be a
> single bit but it is bilateral communication.

As I indicated, I've got no experience with physics experiments.
I do have quite a bit (although years ago) with data from
meteorology  and satellite observations) and the categories
above don't quite work.  In those cases, at least in my
experience, the sensor is paired with a sampling arrangement and
a transmission device, and the transmission device is strictly
one-way, without acknowledgements and often without flow
control.   The problem with even one-bit flow control is that it
requires data buffering and, at least in my time, there was
often a better use of resources than pairing buffering (or any
two-way protocol capability) with the sensor.   Conversely, the
sensors themselves, and what they were measuring, could never be
considered 100% accurate or consistent, so any use of the data
at the far end of the link required smoothing or filtering and
it didn't make much difference whether what was smoothed or
filtered out were occasional erroneous (or sufficiently deviant)
measurements, errors in transmission, or dropped sets of
readings.

That approach obviously becomes a lot less useful in situations
in which one is trying to observe very rare events or when, to
paraphrase John Tukey, the residuals or rough are much more
important than the smoothed data themselves.

> A unilateral communication is simply a bilateral communication
> where only one party has something interesting to say. I don't
> see how it could be imputed to create a need for applications
> to concern themselves with IP header contents or have any
> other architectural consequences.

If you change that definition into "a bilateral communication
where only one party has anything at all to say", I could agree
with you, but it seems to me that such a communication is
tautologically not bilateral, especially when the sender simply
broadcasts with the expectation that someone might be listening
(a broadcast without that expectation takes down the path toward
trees falling in empty forests and I don't think anything would
be served by going there).

> As a former control engineer, I tend to consider any
> communication loop without feedback as being inherently
> broken. 

I would have said that a communication loop without feedback is
not a communication loop.   _Transmission_ mechanisms without
feedback can be designed so that the assumption of delivery
depends on design and statistical quality control mechanisms,
not feedback loops.  All things being equal, they are less
desirable that loops with feedback, but sometimes things are not
equal. 

> If a thing is worth saying then it is worth making
> sure that it is listened to. Sure there are communications
> media such as satellite that are inherently one-way. Such
> media require a completely different architectural approach if
> used alone.

And that was, I thought, the point that others were trying to
make.

> From the apps point of view I don't see why an application
> interface to a multicast stream should look any different from
> an application interface to a unicast stream.

At a network level, I tend to agree.  But, if transmission-only
media require a different architectural approach, hiding that
approach from the receive-only application may or may be worth
the trouble and/or feasible.   If the application wants any data
bundles/ bursts that arrive, together with any sequencing or
time stamp information that may be part of those bursts, the
question of what to do about the bursts that don't arrive (and
that must be presumed to have not been sent or lost in transit
depending on what information is in the bundle) is an
application problem, not a network one.   I think that takes us
quickly into a debate about layering models that, while
interesting, probably would shed no light on the issue.

>  In fact any distinction is a fault in my view.

Well, in an IP-like model, it implies that the application has
to receive the raw datagram stream since only it can have the
context and subject matter expertise to process the data and
interpret what is not delivered.  That makes it quite different
from an application that runs over, e.g., TCP or even one that
works with UDP with reliability, packet reassembly, or flow
control extensions.  The traditional Internet assumption that a
packet either arrives or is lost does not really apply because
information content depends on the stream, not just individual
packets.  I don't know if that is a fault; it is certainly
somewhat different.

> One of the limitations of TCP/IP for apps developers is that
> it requires applications to merge control and data into a
> single channel. A better applications interface would allow
> these to be separated (c.f. DIME, BEEP etc) so you have a data
> channel paired with a (possibly lossy, possibly
> unidirectional) data channel.

That is an interesting comment given how recently people were
denouncing the one major application that separates control and
data channels as hopelessly outdated and generally hopeless.

> Then write a network stack that allows such a connection to be
> established and opportunistically make use of whatever network
> resources are available at each end.
>...

You are moving off into what I believe to be an entirely
different issue -- your theories about resource location in
network designs-- and that is one on which I have no desire to
comment.   

    john

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Dec 2008 07:37:42 -0800

>not wasting your/our time on it?
 
Because the obvious confusion in this area might be the result of the problem being very hard rather than other explanations. Because when there is obvious confusion the source of the dispute might be the confusion rather than an actual difference of opinion as to facts or desirable outcomes.
 
Because any topic that is worth devoting an IETF plenary to and the attention of the IAB, is also worth the attention of the IETF list.

>data channels as hopelessly outdated and generally hopeless.

FTP tries to do the right thing, but does so in a manner that makes a number of assumptions that are increasingly not true. In particular it assumes that if A can read B then B can reach A.
 
I take this as a sign that the protocol is inadequately abstracted from the transport. We need to have control/data separation within a single IP/Port connection bundle. The network middlebox infrastructure needs to know that the two channels are interdependent. Nor is it a necessary assumption, there is no reason that the data channel should be opened in the opposite direction (in fact it isn't on many modern systems). So we end up relying on the weaker assumption that if A can reach B on IP port X, then A can reach B on IP port Y. But even that is unnecessary, it could be reduced to A can reach B on IP port X, then A can reach B on IP port X without loss of functionality.

FTP uses the control/data separation to do a number of interesting things, like allowing A to open up a data transfer between two remote points B and C. But it is also entirely embedded in obsolete modes of interaction. The FTP control channel is conceived as a human/machine connection, which is why it is layered over Telnet according to the spec.

If we are going to be serious about multi-media transport and use multicast effectively I want to be able to do things like:

Alice decides to watch the superbowl, she turns on the TV and selects the channel multicasting the superbowl.

   * A multicast session is set up to obtain packets in realtime from the broadcast source

Alice presses pause

   * Local application buffers data

Alice switches off TV

   * Multicast session is shut down

Bob comes over to watch with Alice, Alice starts TV and tells it to resume from the point she left off.

   * Unicast session is set up to local storage

Alice and Bob skip the game to watch the ads (its the superbowl), they skip forward to live

   * Application switches to using the live feed.

Now currently the protocol abstractions for managing a unicast and a multicast session are very different and coding this type of scheme would essentially require the programmer to develop an abstraction that allows unicast and multicast streams to be used interchangeably.

We actually have a window of opportunity here. XML is increasingly used for the control channel and uncompressed XML really isn't very satisfactory as a data transport for motion video.

>network designs-- and that is one on which I have no desire to

Only you just did.

My entire point, from start to finish was the need to have a clear view of the Internet architecture that takes into account that the 2008 Internet is not the 1980 Internet. We have learned much since, we use the net in different ways since. We cannot roll back Layers 1 through 6 to their pristine state in 1980 when nobody completely understood what they were going to be used for. But what we can do is to adapt layer 6 so that Layer 7 can act as if Layers 1-6 were pristine. And that is in fact the purpose of a layer model.

At the plenary I raised the topic of encapsulation. What is the encapsulation for the IETF? What are the interfaces that it needs to expose to the outside world?

*	It needs to interface to the people developing the layer 2 transport
*	It needs to interface to the people developing applications outside the IETF
*	It needs to tell layer 3-6 implementors what they need to do for interoperability 

At the moment there is a piecemeal approach. And I think that hurts IPv6 deployment. There is no Gestalt. I think that is what we need which is why I am trying to get the IETF list to continue this discussion.

.