GitLab

We had a meeting about proposal 324, and came up with some changes we want to make ... or at least to think about.

Next steps (minor editorial):

• clarify that complete algorithm is summary.
• clarify that there are only two ways to notice congestion.
• define RTT_min,
• define all symbols, and label which are per-circuit, per-consensus, constant, variable, etc
• CCtrl=1 becomes FlowCtrl=2
• Instead of suggested "put data in sendme cells" optimization, use refer to cell-packing optimization.
• Backward_ecn: make it separate proposal or appendix?

Next steps (changes):

• omit SENDME from counting towards windows.
• count INTRODUCE1 for consistency, but clarify that it isn't end-to-end.
• Have initial congestion windows change ... so that there's an allowed range and a suggested value. Reject any circuits that pick a circuit window outside the range.
• clarify use of hs-ntor handshake for negotiating initial windows and increments. (the hs-ntor variant allows including extra data.)

Next steps (design and thinking):

• let's think about what to do with DROP cells and decide what to do if we need to have them count towards window, or sometimes count to window. (Or make sure that we have some other mechanism to absolutely prevent drop-based congestion.)
• Specify how to find initial RTT estimate. (begin/connect, extend/extended, extended/next-cell on relay side.)
• Do we need a maximum window?
• Maybe we don't want a constant sendme reply schedule. Let's see if we want to do "after 10, after 50, after 100". [This may be premature complexity.]
• Clarify what we do if receive window becomes negative.
• Backward_ecn: consider variable-length cell that works a bit like DESTROY? (Crypto shennanegans make nick twitchy)
• Clarify what kind of division you want in these algorithms. (Either truncate or round-to-nearest-int or fixed-radix and count nths of a cell)

@mikeperry is going to look over this list and decide what he wants to take; I'm happy to take on the others.