You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Personally I would say the text "When the datagram option is used, MP-QUIC provides a congestion-controlled unreliable unordered datagram service, similar to MP-DCCP" is unnecessary. Yes, MP-QUIC is an alternative to this protocol. But I suspect what readers would find more helpful is a little more description of the differences between the two. For example, MP-DCCP is simpler to implement and more efficient for already-encrypted traffic.
One thing it does say is that "MP-DCCP defines procedures that facilitate subsequent reordering." Why should the reader care about this? I can imagine a shrug of shoulders. But if you add that reordering has been observed to result in improved end-user throughput, then they will probably take notice.
3 Requirements Language
It feels odd this being a top-level section. Normally it's a subsection of the introduction.
4 MP-DCCP Protocol
Why mention "NN indicates this is non-negotiable" if we are not specifying NN?
4.1
Typo "ore".
It states that the Version MUST be 0, which appears to conflict with the following text about negotiating version 1 or 2. If this isn't a conflict, adding some additional text explaining why would help.
4.2.5
In the first sentence I suggest adding "48 bit", i.e. "The MP_SEQ suboption is used for end-to-end 48 bit datagram sequence numbers of an MP-DCCP connection".
4.2.10
This section doesn't explain the relative meaning of different levels from 3 to 15. An example is that if I have a pair of paths with priorities 3,4 will this be used in the same way as a pair with priorities 3,15? It's probably best for this section to point to section 4.11.
4.7
It would be good to caption the figure to indicate it shows the "most common state transitions".
The text was updated successfully, but these errors were encountered:
1.0 Introduction
Personally I would say the text "When the datagram option is used, MP-QUIC provides a congestion-controlled unreliable unordered datagram service, similar to MP-DCCP" is unnecessary. Yes, MP-QUIC is an alternative to this protocol. But I suspect what readers would find more helpful is a little more description of the differences between the two. For example, MP-DCCP is simpler to implement and more efficient for already-encrypted traffic.
One thing it does say is that "MP-DCCP defines procedures that facilitate subsequent reordering." Why should the reader care about this? I can imagine a shrug of shoulders. But if you add that reordering has been observed to result in improved end-user throughput, then they will probably take notice.
3 Requirements Language
It feels odd this being a top-level section. Normally it's a subsection of the introduction.
4 MP-DCCP Protocol
Why mention "NN indicates this is non-negotiable" if we are not specifying NN?
4.1
Typo "ore".
It states that the Version MUST be 0, which appears to conflict with the following text about negotiating version 1 or 2. If this isn't a conflict, adding some additional text explaining why would help.
4.2.5
In the first sentence I suggest adding "48 bit", i.e. "The MP_SEQ suboption is used for end-to-end 48 bit datagram sequence numbers of an MP-DCCP connection".
4.2.10
This section doesn't explain the relative meaning of different levels from 3 to 15. An example is that if I have a pair of paths with priorities 3,4 will this be used in the same way as a pair with priorities 3,15? It's probably best for this section to point to section 4.11.
4.7
It would be good to caption the figure to indicate it shows the "most common state transitions".
The text was updated successfully, but these errors were encountered: