On Jun 30, 2014, at 2:53 PM, Michael Welzl <[email protected]> wrote:
> > On 30. juni 2014, at 19:03, Joe Hildebrand (jhildebr) <[email protected]> > wrote: > >> On 6/27/14, 8:45 AM, "Michael Welzl" <[email protected]> wrote: >> >>> 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, ..)? >> >> Maybe, if we also have: >> >> - retransmission >> - order preservation >> - optional nagle-ish grouping >> - optional FEC >> - whatever else I'm missing >> >> At which point it might be straightforward to build a stream, but we still >> might want to suggest how to combine the characteristics together into a >> larger bit of functionality. > > Sure; you can do all these things with messages, but it's harder or in some > cases impossible with streams. You can turn much into a stream but not vice > versa. Case in point: Minion - by merely introducing a marker in the byte > stream that separates messages, all kinds of good things become possible. Messages can be turned into streams and streams can be turned into messages, but there's an efficiency cost when the application data model doesn't match the network data model. However, there's a lot more to life than just messages or streams, i.e., that's only 2 of many alternatives. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
