Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

[Bob Briscoe <[e-mail]>]

Yoshi, Markku,

Many of the technical points Markku raised were important omissions from 
the rfc8312bis draft. Whatever status we give the eventual RFC, they 
should be highlighted as areas that need further work, either known 
weaknesses or just areas where we don't have enough data to know whether 
they are weaknesses. I tried to help find useful references for 
experiments already done around those points, and I tried to help write 
such text.

However, I cannot agree with some of Markku's statements about process.


      #1: The rules can change

It's OK to quote RFCs, but it's also OK for us to reach consensus that 
certain aspects of old RFCs are outdated, as long as we give our 
reasons, and there is rough consensus around that. We are all consenting 
adults - we don't have to be limited by RFCs from the past if we 
collectively don't want to be.

I have not noticed a need for the above "rule #1" in this discussion 
yet, but I'm just putting it out there, so if anyone needs to invoke it 
later, they can't be accused of inventing a rule for their own convenience.


      #2: There is no TCP-compatibility requirement

Yes, CUBIC is not TCP-compatible. But that's a feature, not a bug. Words 
like 'TCP-compatible' or 'fair' sound nice, but do not be fooled into 
thinking that an RFC recommends or requires you to behave in a certain 
way just because it has used a nice-sounding word for it.

For an RFC to recommend or require something, it has to say SHOULD or 
MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks about 
what is necessary to be 'fair', it implies nothing about whether you 
should or must be TCP-compatible, or fair; unless it actually says you 
SHOULD or MUST be TCP-compatible, or fair. *No RFC says that.*

BCP 133 [RFC5033] and others have written careful words about straying 
from equal flow rates (quoted below). That gives a checklist for people 
like us who come along later. But it also respects our right to make a 
decision on whether/how to publish a CC RFC based on our own present-day 
knowledge and experience. To quote the relevant guideline in BCP 133 
[RFC5033]:

    (1) Impact on Standard TCP, SCTP [RFC2960  <https://www.rfc-editor.org/rfc/rfc2960>], and DCCP [RFC4340  <https://www.rfc-editor.org/rfc/rfc4340>].

        Proposed congestion control mechanisms should be evaluated when
        competing with standard IETF congestion control [RFC2581,
        RFC2960  <https://www.rfc-editor.org/rfc/rfc2960>,RFC4340  <https://www.rfc-editor.org/rfc/rfc4340>].  Alternate congestion controllers that have a
        significantly negative impact on traffic using standard
        congestion control may be suspect and this aspect should be part
        of the community's decision making with regards to the
        suitability of the alternate congestion control mechanism.

        We note that this bullet is not a requirement for strict TCP-
        friendliness as a prerequisite for an alternate congestion
        control mechanism to advance to Experimental.  As an example,
        HighSpeed TCP is a congestion control mechanism that is
        Experimental, but that is not TCP-friendly in all environments.
        We also note that this guideline does not constrain the fairness
        offered for non-best-effort traffic.

        As an example from an Experimental RFC, fairness with standard
        TCP is discussed in Sections4  <https://www.rfc-editor.org/rfc/rfc5033.html#section-4>  and6  <https://www.rfc-editor.org/rfc/rfc5033.html#section-6>  of [RFC3649  <https://www.rfc-editor.org/rfc/rfc3649>] (HighSpeed TCP)
        and*using spare capacity*  is discussed in Sections6  <https://www.rfc-editor.org/rfc/rfc5033.html#section-6>,11.1  <https://www.rfc-editor.org/rfc/rfc5033.html#section-11.1>, and12  <https://www.rfc-editor.org/rfc/rfc5033.html#section-12>
        of [RFC3649  <https://www.rfc-editor.org/rfc/rfc3649>].

The rfc8312bis draft has a section on 'using spare capacity' precisely 
because that's what was considered acceptable about CUBIC and the new 
generation of hi-BDP CCs developed at that time, as I've emphasized in 
the last para above.


      #3: A process for publishing EXP RFCs doesn't cover publishing
      non-EXP RFCs (by definition)

This IESG statement on "Experimental Specification of New Congestion 
Control Algorithms 
<https://www.ietf.org/about/groups/iesg/statements/experimental-congestion-control/>" 
says it defines the process for a CC to be published as an Experimental 
RFC. It does not say it is the process that /all/ CCs have to follow to 
enter the standards track.

Before invoking that process, one has to determine whether it is 
applicable to this case. The IESG statement contains a sentence about 
how to determine its applicability:

    The decision of whether a specific new congestion control schemes
    goes beyond the principles of [RFC2914] and hence will undergo the
    process described in this document lies with the transport area
    directors, who will use the expertise of the transport area
    directorate and other congestion control experts to aid their decision.

Since RFC2914, we've had RFC3246 explaining why Reno is unscalable, and 
RFC5033 (quoted above) giving guidelines for designers of new CCs. So we 
can debate whether the process that Markku quoted is relevant to this 
case, to help the AD to decide whether to follow the process or not.


      #4 EXP or STD? My view

Reno is worse than other CCs in some respects. Nearly everyone has 
abandoned it. So, if someone asked you why Reno is the IETF's only stds 
track CC, what would you say ...?

As I already said, we have to stop thinking that the stds track requires 
a CC algorithm to be perfect. A CC certainly mustn't have failure or 
collapse modes, but it's performance doesn't have to be perfect in all 
cases. For instance, CUBIC has known poor utilization over radio links. 
That didn't stop Reno from being on the stds track. For me, the IETF 
needs a new CC on the stds track, and CUBIC is the most natural candidate.

However, we must not set a precedent for any old CC to move to the stds 
track. So we must document it's weaknesses and failings, and explain why 
they are not serious (if that is the case).

New CCs need to interoperate with the most prevalent CC on the Internet 
(CUBIC). The IETF cannot even say that as long as it hasn't formally 
recognized CUBIC on the stds track. That is a failing of *us* in the 
tcpm WG. We can move CUBIC to stds track via the exp track if we have 
to, or we can go straight to stds track. The only difference is that the 
first option makes us look like jobsworths for longer.

jobsworth
/ˈdʒɒbzwəːθ/
/noun/
  derogatory•informal
an official who upholds petty rules even at the expense of humanity or 
common sense.
1970s: from "I can't do that, it's more than my job's worth."


Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/