On Tue, Sep 6, 2011 at 1:19 PM, SCHARF, Michael
<[email protected]> wrote:
> 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.
>
I think one-size-fits-all is a dangerous claim for anything. I looked
for and was surprised not to find a disclaimer at the beginning of
5.6.3 (or at least 5.6.3.1.1). And certainly we took this into
account in the design---for example in 5.5.1.6, DTLS/UDP with Simple
Reliability (as specified in the document) is the lowest priority
option. But we can be a bit clearer in 5.6 as to the limitations of
what's there and the reasons.
>
>> > 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?
>
>> > 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.
>
It's a sequence number, it's just not conflating the index of data in
a stream with the retransmission of fragments, as we are all used to
with TCP. Being able to calculate RTTs from every ACK is a really
useful feature.
>
>> 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
>
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
