Re: revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt - result when negotiation fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Replacing this paragraph

   When the Send RTT Estimate Feature is disabled, the sender MUST NOT
   send RTT Estimate options on any of its packets, the receiver MUST
   ignore the RTT Estimate Option on all incoming packets, and SHOULD
   try to estimate the RTT in some other way (not specified by this
   document).

with

   When the Send RTT Estimate Feature is disabled, the receiver MUST
   estimate the RTT as previously specified in RFC4340/4342/5622.

would be acceptable, as I said.

Eddie



On 11/05/2010 05:28 AM, Gerrit Renker wrote:
Hi Eddie,

I am sorry if my previous email has offended you, that was certainly not
my intention.

I think that neither I nor you are right here -- it is not as easy as
saying, "basta, we leave it like that, end of story".

Your suggestion of treating this issue separately is a good point. Since
whether allowing options to appear without negotiating a corresponding feature
seems to be more of a case-by-case issue:

  * in an earlier email you mentioned an RFC where apparently sending options
    before completing feature negotiation is helpful;
  * there are other cases where both allowing and disallowing gets in the way,
    as in the Sender RTT Estimate case: it is like having two oscillators but
    a CPU can be clocked only by one;
  * this may also shed light on which options are truly "optional", i.e. not
    essential to the operation of DCCP.

I don't mind to do the extra work of coming up with a list, but that can only
be a starting point.

With regards to the draft, the 'MAY' has become an unnecessary stumbling
block. Is it an agreeable compromise to completely leave this sentence out,
i.e. no more MUST NOT, but at the same time no guidance when using the option
in an unspecified way?

That is the state of the discussions with Gorry, but apparently I did not
formulate this very well in the emails.

And perhaps I misunderstood your minimal necessary specification:

  "The minimal necessary specification would be

     When the Send RTT Estimate Feature is disabled, the receiver MUST
     estimate the RTT as previously specified in RFC4340/4342/5622."

If we can leave out the MUST NOT part, then "less is more". Would that
be ok?

Gerrit



Quoting Eddie Kohler:
Gerrit:

As I have explained now several times, all analogous features in DCCP are
defined with MUST/MAY language.  You continue to use language like
"bypassing feature negotiation" that is simply not a correct description
of the spec. Feature negotiation is not being bypassed, as I hope you
understand; the features just don't mean what you want them to mean, and
never did.

Though I haven't double-checked, I believe that NO existing DCCP spec
(except DCCP-Thin, which has expired) tells a sender that it MUST NOT
send an extension option when a feature is off.
The sender RTT estimate option is not worth making the DCCP specs
internally inconsistent.

I will not support this draft unless a change is made to MUST/MAY behavior.

If you want to change DCCP's supposedly "ugly" MUST/MAY behavior, you
should do so for all corresponding options in a separate draft, rather
than add to that ugliness by introducing a new form of behavior.  Perhaps
other people on the list would support you.  I wouldn't.

I owe you other comments on the rest of the draft but this is my last
word on this.

Eddie


On 11/02/2010 05:25 AM, Gerrit Renker wrote:
    My issue  is simply that all other analogous option/feature combinations in DCCP
are specified like this:

      DCCP A MUST send Ack Vector options on its acknowledgements when Send
      Ack Vector/A has value one, although it MAY send Ack Vector options
      even when Send Ack Vector/A is zero.

This was intentional; I can explain more if you care.
Please do - I asked for that in the previous email.

I can not see the point of doing the above.
It says "you MUST do A, but you MAY also not do A".

No, it doesn't.  The plain language of the feature description says
- If the feature is one, the sender MUST send the option.
- If the feature is zero, the sender MAY send the option.
This is not a contradiction.

I did not say it is a contradiction and what you say above in a way paraphrases
what I said above, hence also no contradiction.


If a sender is permitted to add the option even if the negotiation means that
it is not permitted to use the option,

The idea of "not permitting" an option is not in the spec; you've
invented it.  An endpoint is always permitted to send Ack Vector options.
   "Send Ack Vector", when on, REQUIRES that an endpoint send Ack Vector
options.  When off, the feature has no effect; the endpoint is still
permitted to send Ack Vector options, *as it always was*.

Perhaps I invented it because I got confused by the specification. If a receiver
may send something without negotiation, then to me this says that the negotiation
is not really required.

Seriously Eddie I don't mean to nitpick here, but this behaviour of requiring
feature negotiation on the one side and allowing to bypass it on the other hand
is one of the most ugly parts in the entire specification, and sorry I remain
reluctant to do the same here.

First, it is the opposite of the Robustness Principle [RFC 4340, 3.6]: it means
being liberal in what the sender is "do"-ing. Throughout the email discussion we
have so far established that we both agree (and as I understand Gorry, he, too)
on the receiver ("accepts") side of the robustness deal.

The second issue is that this extra rule of allowing a sender to bypass feature
negotiation seems to make sense only in theoretical thinking. In practice,
within an implementation, the endpoints have to negotiate about their feature
sets anyhow; adding a few more bytes to make clear whether to use/not-use Ack
Vectors, Send Loss Event Rate, Sender RTT Estimate almost does not increase the
complexity at all.

There is at least one feature negotiation during the lifetime of a connection,
when exchanging Request/Response, so it can be assumed that any implementation
will be able to perform at least one clear feature negotiation.

Third, I don't like to see all the good work you and Sally put in to make feature
negotiation clear and unambiguous to be diluted by this anti-robustness rule.


Among the reasons that we preferred MUST...MAY for features like this:

- It allows an endpoint to generate an option unconditionally, which
might be preferred for simplicity of implementation.  Sender RTT
Estimate, CCID-3 Loss Event Rate are good examples.

Sorry, but exactly the opposite is the case. The Linux implementation makes sure
that Loss Event Rate feature and ECN capabilities are negotiated, hence there are
no in-between states. This does not increase complexity, all it boils down to is
adding a few table entries.

But since the implementation always sticks to yes/no, it ignores the 'MAY' with
regard to sending options outside of any feature negotiation.

Which is why I don't like to add the same to the present specification. It is
adding something that ends up having to be ignored just to make the
implementation work at all.

- When an extension-feature is off (zero), we don't constrain endpoints'
behavior.  That is key to forward compatibility; an endpoint by
definition cannot be constrained by an extension that does not yet exist.

But as far as I can read this, this also means the receiver end, where we three
already agree. The receiver just ignores the option, which is clear and unambiguous.

I can see only disadvantages of allowing A and not-A.  Apart from making the
implementation complex and confusing,

Doubt it.  Among other reasons, for senders, the behavior you prefer
("MUST...MUST NOT") is a strict subset of the behavior we allow
("MUST...MAY").

Please can you state the other reasons then?

The sender is more conservative on the outgoing side than on the incoming side
because of the robustness principle.





[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux