Yingzhen-ietf
commented
3 years ago I didn’t understand “the types of sessions”. What do “types” refer here?
There is a difference between multisession and one session with multiple streams.
If we support multisession, but one session one (or maybe more) stream, it means there will be multiple FSMs equal to sessions to maintain. The overhead is not trivial (for example, two sessions for IPv4 unicast).
If we support one session with multiple streams, there is one FSM (sort of like HQ’s draft in a session level), but more data channels. You can still achieve sending some updates faster, but the session will have to reset in case of error.
There are different design options, we need to debate and pick one. My personally feeling is that sometimes too many flexibilities may cause implementation difficulties and bugs.
Another concern is about the QUIC implementation itself, whether too many streams will work as promised.
Thanks, Yingzhen
On Aug 18, 2021, at 1:54 PM, Alvaro Retana @.***> wrote:
Why do we need to limit the types of sessions? If the same AFI/SAFI is signaled in the OPEN of more than one stream, why should we not allow that?
There might be applications where an operator wants to create multiple sessions in order to prioritize the routes: "important", "not-so-important" on different sessions. Yes, this means there will be additional overhead in terms of policy configuration, but that's up to the operators. If both sides are ok with multiple sessions then it should be ok.
Another application could be redundancy: advertise the same thing on both sessions, maybe time-shifted: if an update results in a reset then not all routes are lost (the time shift helps with that).
What is the downside? If we end up with 2 (or more) IPv4 sessions, then the receiver either has to also incur the policy configuration overhead (without really knowing exactly what the sender will send [*]), or the receiver simply merges everything into the same table.
[*] We could add an opaque field to the capability (16 bits should be more than enough) so that the neighbors can signal stuff between them: "this session is meant for VPN 5" or "always prefer these routes". It would sort of act as a community-type signal for the whole session -- we don't have to specify what it does.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Yingzhen-ietf/BGP-QUIC/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURDC47TO3UOFGUJDZ3GFIDT5QMZTANCNFSM5CM2SXJQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.
aretana
Why do we need to limit the types of sessions? If the same AFI/SAFI is signaled in the OPEN of more than one stream, why should we not allow that?
There might be applications where an operator wants to create multiple sessions in order to prioritize the routes: "important", "not-so-important" on different sessions. Yes, this means there will be additional overhead in terms of policy configuration, but that's up to the operators. If both sides are ok with multiple sessions then it should be ok.
Another application could be redundancy: advertise the same thing on both sessions, maybe time-shifted: if an update results in a reset then not all routes are lost (the time shift helps with that).
What is the downside? If we end up with 2 (or more) IPv4 sessions, then the receiver either has to also incur the policy configuration overhead (without really knowing exactly what the sender will send [*]), or the receiver simply merges everything into the same table.
[*] We could add an opaque field to the capability (16 bits should be more than enough) so that the neighbors can signal stuff between them: "this session is meant for VPN 5" or "always prefer these routes". It would sort of act as a community-type signal for the whole session -- we don't have to specify what it does.