Purpose of UNIDIRECTIONAL flag

[Alek Storm]

There may be something obvious I'm missing here, but why is the UNIDIRECTIONAL flag on SYN_STREAM necessary? Can't its value be gleaned from comparing the Associated-To-Stream-ID field to 0? It's probably safe for a client to assume that an incoming SYN_STREAM is meant to be unidirectional, anyway.

Alek

[Simone Bordet]

Hi,

Regarding the latter, in pure SPDY (without HTTP) there is nothing
that says that the receiver of the connection cannot initiate normal
SPDY streams towards the initiator of the connection, so I won't
assume unidirectionality just based on who received the SYN_STREAM: we
need to be able to tell, either via the flag or via comparison with
the associated stream ID.

Simon
--
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

[Alek Storm]

Interesting. Are there any use cases for using SPDY framing, while ignoring HTTP semantics? Are there other protocols it could carry?

Alek

[Simone Bordet]

Hi,

On Wed, May 23, 2012 at 1:20 PM, Alek Storm <alek....@gmail.com> wrote:
> Interesting. Are there any use cases for using SPDY framing, while ignoring
> HTTP semantics? Are there other protocols it could carry?

While SPDY has been designed from ground up to support HTTP, it is
flexible enough to allow to carry other protocols, for example
WebSocket.
CometD is based on a protocol called Bayeux, which is currently
transported over HTTP and WebSocket, but may be transported over SPDY
as well (i.e. CometD uses the SPDY framing layer in the same way it
uses the WebSocket framing layer to transport Bayeux messages).

If you have an environment where you know your clients are SPDY only,
you can design your own protocol and transport it over SPDY.
Jetty offers a pure SPDY client (i.e. not bound to HTTP) that you can
use for that.

[Alek Storm]

Thanks. Is that the reason for the UNIDIRECTIONAL flag? That some non-HTTP protocols carried over SPDY might use unidirectional streams without associating them to another stream?

Alek

[Thomas Becker]

A UNIDIRECTIONAL stream must have an associated stream id. You're right
that the UNIDIRECTIONAL flag is not necessarily needed, but still it
serves a purpose:

http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-4.6-Unidirectional-streams

--
thomas becker
tbe...@intalio.com

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)

[Alek Storm]

Okay, then I propose it be removed in spdy/4. It's entirely redundant.

Alek

[Alek Storm]

Just read the link you posted (didn't notice it before, sorry). Removing UNIDIRECTIONAL would not mean clients would have to send SYN_REPLY+FIN upon receiving a pushed stream, because the stream's unidirectionality is already indicated by the Associated-To-Stream-ID field.

Alek

[Thomas Becker]

I agree.

On Wed May 23 22:29:11 2012, Alek Storm wrote:
> Just read the link you posted (didn't notice it before, sorry).
> Removing UNIDIRECTIONAL would not mean clients would have to send
> SYN_REPLY+FIN upon receiving a pushed stream, because the stream's
> unidirectionality is already indicated by the Associated-To-Stream-ID
> field.
>
> Alek
>
> On Wed, May 23, 2012 at 3:23 PM, Alek Storm <alek....@gmail.com
> <mailto:alek....@gmail.com>> wrote:
>
> Okay, then I propose it be removed in spdy/4. It's entirely redundant.
>
> Alek
>
>
> On Wed, May 23, 2012 at 3:21 PM, Thomas Becker
> <tbe...@intalio.com <mailto:tbe...@intalio.com>> wrote:
>
> A UNIDIRECTIONAL stream must have an associated stream id.
> You're right that the UNIDIRECTIONAL flag is not necessarily
> needed, but still it serves a purpose:
>

> http://www.chromium.org/spdy/__spdy-protocol/spdy-protocol-__draft3#TOC-4.6-Unidirectional-__streams

> <http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-4.6-Unidirectional-streams>
>
>
> On Wed May 23 22:11:18 2012, Alek Storm wrote:
>
> Thanks. Is that the reason for the UNIDIRECTIONAL flag?
> That some
> non-HTTP protocols carried over SPDY might use
> unidirectional streams
> without associating them to another stream?
>
> Alek
>
> On Wed, May 23, 2012 at 6:32 AM, Simone Bordet
> <sbo...@intalio.com <mailto:sbo...@intalio.com>

> <mailto:sbo...@intalio.com <mailto:sbo...@intalio.com>>>

> wrote:
>
> Hi,
>
> On Wed, May 23, 2012 at 1:20 PM, Alek Storm
> <alek....@gmail.com <mailto:alek....@gmail.com>

> <mailto:alek....@gmail.com

> tbe...@intalio.com <mailto:tbe...@intalio.com>

[Hark Lee]

I agree 2,if there r two ways identify the  UNIDIRECTIONAL  , one of them should be removed.

2012/5/24 Thomas Becker <tbe...@intalio.com>

[Alek Storm]

It's been about a week - does anyone else have any opinion for/against removing UNIDIRECTIONAL? I'm sure the editors would like more of a consensus before making any changes.

Alek

[Alek Storm]

Er, please? Is there anything else I need to do to make this a formal proposal? I would appreciate some guidance here.

Thanks,

Alek

[Antonio Vicente]

Other than being redundant, is there anything that motivates your proposal?  We're talking about data carried in a bit-field that is currently not being used for much other than FIN flags.

[Alek Storm]

On Sun, Jun 3, 2012 at 12:44 AM, Antonio Vicente <a...@google.com> wrote:

Other than being redundant, is there anything that motivates your proposal?  We're talking about data carried in a bit-field that is currently not being used for much other than FIN flags.

Nope, no other reason :). But both Occam's Razor and implementation experience tell us that the simplest version of the protocol should be preferred. It's true, the flag space isn't exactly crowded, but it could be someday if we make redundancy acceptable in designing the protocol.

I just found https://github.com/mbelshe/SPDY-Specification/tree/gh-pages - should I make a pull request?

Alek

[Alek Storm]

I've opened a pull request, although I'm still unsure whether I'm following proper procedure.

Alek

[Roberto Peon]

That procedure is fine.
We need to make the SPDY/4 repository for this + flow control changes.

That will push what we were calling SPDY/4 ( explicit proxy support, name and cert data push)  to SPDY/5.

-=R

[William Chan (陈智昌)]

Just chatted with Roberto. To clarify, we're keeping the existing repo as "HEAD" and we'll branch SPDY/4 to dev.chromium.org/spdy when ready.

[Mike Belshe]

I don't think this is a big deal, we can make the change.

For the record, the UNIDIRECTIONAL was not written as exclusively for PUSH streams.  If we use the "associated-stream-id != 0" to infer UNIDIRECTIONAL, that has the side effect of making all server pushes unidirectional (probably ok) and also making UNIDIRECTIONAL not-possible on non-push streams.

I find the inferred semantics to be less clear than the explicit ones.  

Nonetheless, this question has come up before, which is why it was explicitly addressed in section 4.6:

"Many readers notice that unidirectional streams are both a bit confusing in concept and also somewhat redundant. If the recipient of a stream doesn't wish to send data on a stream, it could simply send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL is, therefore, not necessary.

It is true that we don't need the UNIDIRECTIONAL markings. It is added because it avoids the recipient of pushed streams from needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose."

Mike

[Alek Storm]

On Mon, Jun 4, 2012 at 12:26 PM, Mike Belshe <mbe...@chromium.org> wrote:

I don't think this is a big deal, we can make the change.

For the record, the UNIDIRECTIONAL was not written as exclusively for PUSH streams.  If we use the "associated-stream-id != 0" to infer UNIDIRECTIONAL, that has the side effect of making all server pushes unidirectional (probably ok) and also making UNIDIRECTIONAL not-possible on non-push streams.

The former is already mandated by section 3.3.1 in v3, and the latter currently doesn't make any sense with HTTP semantics. If we find a use for unidirectional non-push streams in the future, we can always add the flag back in.

Nonetheless, this question has come up before, which is why it was explicitly addressed in section 4.6:

"Many readers notice that unidirectional streams are both a bit confusing in concept and also somewhat redundant. If the recipient of a stream doesn't wish to send data on a stream, it could simply send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL is, therefore, not necessary.

It is true that we don't need the UNIDIRECTIONAL markings. It is added because it avoids the recipient of pushed streams from needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose."

In the pull request, I've updated that section to read:

"Besides providing a clear endpoint for unidirectional streams, Associated-To-Stream-ID also avoids the recipient of pushed streams from needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) to signal that it doesn't wish to send data on the stream."

I would have preferred to delete the section entirely, but chose this rewording to keep the change as conservative as possible. What do you think?

Alek