mpiraux / draft-piraux-quic-tunnel

IETF draft for QUIC tunnels
Other
0 stars 0 forks source link

Adds a lightweight mode #4

Closed mpiraux closed 4 years ago

masputra commented 4 years ago

On the lightweight mode, I was under the impression that it too would be leveraging the unreliable datagram extension as per draft-pauly-quic-datagram, but it looks like this text is specific to the datagram mode instead? I'm hoping that's just a misplaced text case, and not by design.

Reading the changes closely, I see that the control TLVs are applicable only to the datagram mode, and that the access availability/unavailability signaling feature would be lost for the lightweight mode. Is this a case where one could open a QUIC connection in datagram mode purely for this type of signaling, while having additional QUIC connections in lightweight mode for the actual data? Would there be a simplistic approach to combine the two, i.e. lightweight mode with control TLVs?

mpiraux commented 4 years ago

On the lightweight mode, I was under the impression that it too would be leveraging the unreliable datagram extension as per draft-pauly-quic-datagram, but it looks like this text is specific to the datagram mode instead? I'm hoping that's just a misplaced text case, and not by design.

Indeed, it's misplaced text. I will clarify that.

Is this a case where one could open a QUIC connection in datagram mode purely for this type of signaling, while having additional QUIC connections in lightweight mode for the actual data?

No that's not what I envisioned. I left this open for out-of-band signalling only taking care of that.

Would there be a simplistic approach to combine the two, i.e. lightweight mode with control TLVs ?

I wondered whether 3GPP values in-band signaling of that sort and whether it wouldn't have be best to leave that out of the lightweight mode. We didn't receive comment on that part so I will put it back in.

I also have to do a pass on the -tcp draft to look for inconsistency with this added mode.