Re: Drafting mux WG charter

> I'm concerned about the idea of the IETF designing a protocol which
> completely punts on security issues.

I agree.  I wasn't trying to suggest a complete punt.  I was trying to say that the "heavy lifting" is done in other layers.  The mux layer would naturally do what's necessary to enable effectively secured stacks to be built using both a mux layer and some security layer(s) (and that would naturally include the mux layer "not blowing it" on its own).


> I'm also uncomfortable with the idea of replicating all the flow-control
> machinery of TCP in a layer above it.  The consequences of doing so should
> be documented and justified.

Yeah, we heard some of this before IETF-43.  You'll see documentation like you've suggested appearing in early drafts of the HTTP-NG charter.  As we progressed on drafting the charter, we got to thinking it would be included in the MUX spec (as design rationale) rather than broken out into a separate document.  To my surprise, this was not even raised at the HTTP-NG BOF, held under Transport aegis, at IETF-43; I took this to mean the community was getting comfortable with the arguments we were making on this point.

Note also that we haven't proposed replicating all of TCP's flow control machinery.  TCP's flow-control machinery includes both sender-side restraint (AKA slow-start) and reciever-given restraint (the windowing explicit on the wire).  The mux needs the latter (at least for applications where you expect some real independence of the message streams), but not the former.  The sender-side restraint is there to avoid flooding the network, and TCP will do that for us even with a mux above it.

Note that the charter isn't explicit on this point.  I anticipate the WG to debate this, and decide that the reciever-given restraint in the mux layer should be an optional module, because some applications will need it and some won't.

Received on Tuesday, 9 February 1999 16:21:10 UTC