I'll just comment on one detail below, as it is indeed important > >> > Section 5.6.3.1: "In general, senders MAY implement any > >> rate control > >> > scheme of their choice, provided that it is REQUIRED to > be no more > >> > aggressive then TFRC[RFC5348]. The following section describes a > >> > simple, inefficient scheme that complies with this requirement." > >> > > >> > => Maybe I again miss something, but as far as I can see > >> the following > >> > sections doesn't fully explain how TFRC is implemented here. For > >> > example, TFRC requires information about the segment size; > >> this is not > >> > considered here. In general, it is not clear to me why a simple > >> > baseline implementation does not follow the TFRC protocol > >> (RFC 5348) > >> > more closely (or a light-weight user-space TCP-like protocol). > >> > > >> > >> again, simplicity won out. We believe what's there is a simpler > >> protocol (the simplest we could think of) that follows the > >> requirement of being less aggressive than TFRC. > > > > Just to repeat what I said: The draft doesn't explain how the > > requirement of being less aggressive than TFRC is indeed achieved. > > > > Regarding this and following discussion, maybe it would be > better to back up a level and make sure we're talking about > the same things. > 5.6.3.1.1, which is the only actual retransmission scheme > defined in the document says: > > The node MUST > double the time to wait after each retransmission. > ... > Once an ACK has been received for a message, the next > message can be > sent, but the peer SHOULD ensure that there is at least 10 > ms between > sending any two messages. > > so this is a stop and wait algorithm with exponential backoff > on retransmissions. Furthermore, > > If all > retransmissions for a message fail, then the sending node SHOULD > close the connection routing the message. > > So it actually abandons a link if retransmissions don't work, > rather than continuing to put traffic into it. > > Is there any actual question that this is a safe (albeit > non-performant) algorithm?
I don't think that the current text in section 5.6.3.1.1 actually describes a stop-and-wait protocol. In my reading, the sentence "Once an ACK has been received for a message, the next message can be sent" does not prevent the sender from transmitting several messages in parallel (but well, I am not a native speaker). To me, the text describes a windowing protocol that is allowed to send one message per 10ms, i. e., in summary 100 messages per second. If this section is about a stop-and-wait protocol, then please mention that and use appropriate normative language. For instance, stop-and-wait would result in something like "The next message MUST only be sent after the ACK of the previous message has been received (or the retransmission finally times out)". One reason why this section may be confusing is the "received" field, as already noted in my review. A stop-and-wait protocol doesn't need it; it only makes sense if there is more than one message outstanding, i. e., if there is a send window. If the intention is to specify a stop-and-wait protocol only, then I suggest to remove the "received" field from the spec. Anyway, other semantics for this field might make sense if a better transport mechanism will be defined in future, as already noted in my review. A stop-and-wait protocol with a single outstanding message (not too large, i. e., not significantly exceeding 3-5 KB) and adaptive RTO including back-off would be rather safe to use and sufficiently TCP friendly, according to RFC 5405. A corresponding rephrasing of these sections might address most of my concerns regarding congestion control. Of course, such a stop-and-wait doesn't make sense for any larger overlay, but apparently we agree on that. Michael
