Re: [Spud] The draft's questions

[Salvatore Loreto <[e-mail]>]

Hi Ted

thanks for listening the questions below.
I have one comment , see in line

On 08 Jul 2015, at 19:35, Ted Hardie <[e-mail]<mailto:[e-mail]>> wrote:

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.

about the “Must all packets in a five-tuple flow have tube-ids if some do”
While I agree that it should not be a MUST because we can not mandate that all the different applications will be updated at the same time
However from the network prospective the “simplest possible thing” would be IMO that all the packets in a five-tuple flow, especially
the ones generated by the same application, looks similar… I mean all of them run over the SPUD layer

best regards
Salvatore


* 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?
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

regards,

Ted
_______________________________________________
Spud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spud