[Spud] The draft's questions

[Ted Hardie <[e-mail]>]

So, the draft asks the following questions, which I am going to answer
based on a simple prejudice:  do the simplest thing that can possibly
work.  I'd be interested to hear other answers and the design rationale
behind them.

* Can one packet belong to multiple tubes?

Nope.  If an overlying protocol needs the same payload in multiple tubes,
it needs new packets for each.  Rationale:  the number of times this is
going to come up seems small for the overhead it would take to support
carrying the different tube-ids within the same packet.

* Do all packets in a five-tuple flow have to belong to one tube?

Nope.  As the WebRTC bundle use cases shows, you may have a single
five-tuple with multiple tubes wanting different treatment by the network.

For the related question of "Must all packets in a five-tuple flow have
tube-ids if some do?", my answer is still "Nope".  If you're not calling
out a grouping of packets for separate treatment by the network, it's up to
you whether you assign a tube-id and say "nothing special needed" or assign
no tube-id at all.  I'd do the latter, because of the "simplest possible
thing" principle.

* Can/Must the backward flow have the same tube ID or a different one?

I don't think it MUST.  I'm of the opinion that it likely isn't a great
idea in general, but you probably need to be able to handle the case where
they are, just for the accidental collision case. (Depending on the
mechanism for generating them, not handling that would make for some deeply
random and very occasional failures).  Ken Calvert has pointed out that if
you actually want different treatment in the forward and reverse direction
that having a different tube-id makes this easier, and that's probably a
good enough reason for a SHOULD NOT.


*  Especially at connection start-up, depending on the semantics of the
overlying transport protocol, there likely might be only one packet to
start multiple streams/tubes. Can this start message signal multiple tube
IDs at once or do we need an own start message for each tube?

If the "Nope" above, holds this, doesn't arise.  If you want to talk about
a tube, send a message about that tube, independently of messages for other
tubes.  For the multiplexed-on-a-five-tuple case, you are then getting a
message per tube, rather than per five-tuple, but that's the cost of
independent treatment by the network.  If you don't want independent
treatment, put them in the same tube.

* Or is it in this case not possible to have multiple tubes within one
five-tuple?

​See above.

Any other prejudices/answers folks want to share?


regards,

Ted