yep - prob best work on this to date is bryan ford's structured streams stuff (in sigcomm 2007) http://www.brynosaurus.com/pub/net/sst-abs.html
On Fri, Jul 11, 2014 at 3:53 PM, Fred Baker (fred) <[email protected]> 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. 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. > > IMHO, the API will do well to let the client advise it regarding what type > of interface it wants, and go with it. > > On Jun 27, 2014, at 7:45 AM, Michael Welzl <[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]> > 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] > 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
