On Jul 13, 2014, at 1:16 AM, Michael Welzl <[email protected]> wrote:
> > On 12. juli 2014, at 21:12, Fred Baker (fred) <[email protected]> wrote: > >> >> On Jul 12, 2014, at 12:47 AM, Michael Welzl <[email protected]> wrote: >> >>> As for Structured Streams, it's a nice paper but I never saw how this is >>> much different from SCTP... >> >> Is that a bad thing? > > For the paper perhaps, in terms of innovation, as it doesn't talk much about > SCTP IIRC… OK. There are at least two ways one can approach this kind of technology: from the perspective of requirements, and from the perspective of innovation. A problem I have with academic papers is that they often innovate for innovation’s sake; they want desperately to create something novel, and will often say repeatedly that whatever their innovation is is novel, as if saying it frequently makes it so. My question is not whether it is novel, unless the novelty represents and actual improvement. My question is whether it meets the requirements. In this case, we have a mechanism that carries data in IP datagrams. The datagrams fundamentally carry one of two kinds of content: messages that are exchanged between communicating peers, such as a BGP exchange might, and streams of data that might carry on interminably, such as an interactive exchange or an A/V application might. A stream must be delivered in sequence; messages might accept delivery out of sequence, or even unreliability. In between, the transport turns application data into IP datagrams and back into application data. The way the transport distinguishes between messages and streams, if it does at all, is its designer’s call. But to say that the needs of two classes of applications are irrelevant because one can be created out of the other - which is the model that TCP used, and the model Sequenced packet used, and the model you propose here - targets the transport at that class of application. I think we’re far better off recognizing that there are multiple kinds of applications, and making an API that works well with either or any of them If that means that the API implements RFC 2126 internally to carry messages over a stream transport, so be it. If it means that the transport internally carries chunks, as SCTP does, and knows whether they are intended to be streams or messages, so be it. But making it an application layer problem doesn’t come across to me as having looked at it from the perspective of the requirements of the application layer. > But my intention was not to criticize the paper. I just meant that it's > similar to multi-streaming in SCTP and thus probably not necessary to > consider as yet another transport for TAPS to think about. > > Cheers, > Michael >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
