Subject: [P2PSIP] Fwd: Auto-discard notification

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 7 Sep 2011 08:43:23 -0400

For some reason, the mailer discarded this message.  Doesn't appear to have hit the list any other way, so I'm forwarding it

Begin forwarded message:

From: "SCHARF, Michael" <[email-masked]<mailto:[email-masked]>>
Subject: RE: tsv-dir review of draft-ietf-p2psip-base-18
Date: September 7, 2011 7:59:11 AM EDT
To: "Bruce Lowekamp" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 8 Sep 2011 12:42:55 -0400

Date: September 8, 2011 3:36:20 AM EDT

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).

The document should probably reference RFC 5405, as the guidelines are
obviously relevant for RELOAD in general.

The first sentence of Section 3.1.1 in RFC 5405 states that TFRC or
something equivalent SHOULD be used once going beyond stop-and-wait. So,
finally it comes down to TFRC whatever reference you use.

IMHO the simplest solution for moving this forward would be just to
specify stop-and-wait and to postpone considerations regarding a
TCP-friendly transport mechanism with better performance to a future
document.

Michael