On 7/11/2014 7:53 AM, Fred Baker (fred) wrote:
This discussion is as old as TCP. One can build a message interface on a
stream interface (RFCs 1006 and 2126) and a stream interface on a packet
interface.
Except for efficiency. A messages on streams can induce delays for
reordering and error recovery that the messages might be able to tolerate.
I.e., that's why we have DCCP and SCTP alternatives.
> When I want to send a large message, such as a file, the
difference between the two is difficult to discern: either way one
slices that cookie, one has a lot of transport PDUs being sent; the only
real difference is at the receiving end, which might want to receive the
stream as it arrives or the message when it has completely arrived.
Even when you send a file, there is a difference depending on the errors
and reordering in the stream. If the source is stable (not ephemeral)
and has no cost to the order of access, the most efficient way is to
send the entire file and go back to fill in the holes as you go. Other
ways induce stalls to ensure that the window 'in memory' is small, which
made sense when RAM was costly.
I.e., there are a LOT of trade-offs in the overall system, and it
depends on way the *entire* system is being used as a whole.
IMHO, the API will do well to let the client advise it regarding what
type of interface it wants, and go with it.
+1
Joe
On Jun 27, 2014, at 7:45 AM, Michael Welzl <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I changed the subject because this is not about the chartering
discussion anymore - it's beginning our work :-)
Toby, in his last email, raised the following question:
On 27. juni 2014, at 16:21, Toby Moncaster
<[email protected] <mailto:[email protected]>> wrote:
[snip]
- message atomicity
What's that? That multiple messages are not combined into one
packet? This plays a role for an application only when there is
significant loss (I think). Wouldn't it be nice to have a system
that provides atomicity only when needed and otherwise saves header
overhead? I would vote against exposing that. Either way, I vote it
off the list that goes in the charter, it's not an obvious service
to me.
To some extent I agree here. But is there any way we can correctly
express the differences between stream and packet oriented transports?
Can we try to make a simple decision here, as a group, to never even
really consider streams at all?
It seems to me to be straightforward to provide a stream-based
transport over a message-based transport, so this is something that
can simply always be done. Thus, can we just write a disclaimer in one
of our documents, recommending that any TAPS-supporting systems can
provide stream-based transport on top of the message based transport
too, but that its users must be aware of limitations that arise from
streams (such as HOL blocking delay, no ALF, ..)?
Cheers,
Michael
_______________________________________________
Taps mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
