On 13. juli 2014, at 19:39, Fred Baker (fred) <[email protected]> wrote:
> > 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. I agree with all of that (and have a feeling that you misunderstood me :-) ). Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
