On Wed, Sep 7, 2011 at 7:59 AM, SCHARF, Michael <[email protected]> wrote: > 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)". >
Agree. > 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. > At one point there was an additional more TCP-like sender algorithm, which we removed at some point due to concerns over complexity and the hope that a suitable alternative would arrive via TSV. But we wanted to leave the receiver algorithm in there as-is with the potential of allowing an improved sender algorithm to interact with it if such a thing evolved. > 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. > On that issue, would it be better to explicitly state section 3.1.1 of 5405 for other non stop-and-wait senders rather than TFRC itself? I'm not quite sure why we were pointed at TFRC---it may have actually predated 5405, but that once you go beyond stop-and-wait, 3.1.1 is the section that applies (as 3.1.3 case 2 points back to 3.1.1). Thanks, Bruce > Of course, such a stop-and-wait doesn't make sense for any larger overlay, > but apparently we agree on that. > > Michael > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
