Some remarks on selected aspects inline.
> > This draft is on the right track but has open issues,
> described in the
> > review. Given the length and complexity of the document, I only
> > comment on transport issues. However, for what it is worth, my
> > personal impression is that other sections not addressed by this
> > review seem to be somehow experimental.
> >
> > My main concern is the Forwarding and Link Management Layer. It is
> > designed to run over different transports, most notably TCP and UDP.
> > Having such a generic transport including built-in NAT traversal
> > support is very valuable. But I find parts of the specification
> > confusing, as explained below. Also, building a simple, generic
> > transport mechanism on top of UDP and TCP (or, DTLS and TLS) is
> > actually something that is hardly specific to RELOAD.
>
> Totally agree. One of the reasons we left room for extension
> points for new transports is in the hope that a more general
> solution will
> become mature enough to be dropped in at a later date. In line with
> that idea, we tried to go for overly simple to avoid spending
> too much time specifying complexity that we hope would be
> replaced with a better solution.
Then we should really avoid that someone read this spec and thinks that
it describes a good one-fits-all solution.
> > 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.
> > Section 5.6.3.1.1: "In each retransmission, the sequence number is
> > incremented."
> >
> > => It would be worth to spend a sentence about the rational and
> > consequences of this. For instance, whether this implies that a
> > receiver may process the original message and the
> retransmission twice.
> >
>
> Happy to spend a sentence on this, but just to be clear, this
> is designed to allow the world's dumbest stop-and-wait protocol.
Well, this sentence prevents even the alternating bit protocol... In
fact, this solution is closer to a timestamp than a sequence number.
> Specifically, the goal of 5.6.3.1.1 is to specify a
> ludicrously simple, totally safe algorithm that is sufficient
> for most envisioned deployments of P2PSIP for implementors
> who don't want to spend the time implementing TFRC. I would
> hope most do spend the time, but it seemed unnecessary to
> specify how TFRC works in this document.
AFAIK, section 5.6.3.1.1 is *not* save as it is, and it does *not*
guarantee that it is less aggressive than TFRC.
The specified protocol is probably save *if and only if* the sender
ensures that only very few messages are sent. Then, section 3.1.2. of
RFC 5405 applies ("Low Data-Volume Applications").
For instance, I guess that the protocol would indeed be OK if the spec
did mandate that only a single message MUST be outstanding on a link.
But, unless I miss something, at the moment there is only an upper limit
to 100 messages/sec. IMHO this is orders of magnitude above the low
data-volume applications discussed in RFC 5405.
> > Section 5.6.3.1.1: "Implementations that use a dynamic estimate to
> > compute the RTO MUST use the algorithm described in RFC
> 6298[RFC6298],
> > with the exception that the value of RTO SHOULD NOT be
> rounded up to
> > the nearest second but instead rounded up to the nearest
> millisecond."
> >
> > => This sentence doesn't cite RFC 6298 correctly. RFC 6298 doesn't
> > mandate to round up to the nearest second. It mandates a
> minimum RTO
> > of
> > 1 second. And I strongly suggest to use such a minimum RTO as well
> > (maybe 500ms as minimum would be OK as well).
> >
>
> I think you refer to where 6298 says:
>
> Until a round-trip time (RTT) measurement has been made for a
> segment sent between the sender and receiver, the
> sender SHOULD
> set RTO <- 1 second, though the "backing off" on repeated
> retransmission discussed in (5.5) still applies.
>
> there's no need for that as ICE has already completed, so we
> have an RTT measurement.
My understanding of this sentence is completely different. In my
opinion, it suggests not to use this part 6298:
" (2.4) Whenever RTO is computed, if it is less than 1 second, then the
RTO SHOULD be rounded up to 1 second."
In other words, Section 5.6.3.1.1 argues that the minumum RTO should be
1ms. IMHO, this value is orders of magnitude too small.
Maybe this is just a phrasing issue. But, again, I think that you should
use a minimum RTO of the order of 500ms independent of how you measure
the RTT. Otherwise, the protocol is very vulnerable to changes of the
path RTT etc.
Michael
