Subject: [tcpm] WGLC for Proportional Rate Reduction

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 8 Aug 2012 12:32:50 +0300

Hi,

As discussed in the meeting last week, we will now start working group last call for "Proportional Rate Reduction for TCP" (draft-ietf-tcpm-proportional-rate-reduction-02), to be published as Experimental RFC. The WGLC runs until Friday, August 24th. Please read the draft and send comments by then. If you have read the draft and think it is ok, notifying just that is also helpful (even without comments).

The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm-proportional-rate-reduction-02 

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Fri, 24 Aug 2012 13:18:30 -0400

> As discussed in the meeting last week, we will now start working group
> last call for "Proportional Rate Reduction for TCP"
> (draft-ietf-tcpm-proportional-rate-reduction-02), to be published as
> Experimental RFC. The WGLC runs until Friday, August 24th. Please read
> the draft and send comments by then. If you have read the draft and
> think it is ok, notifying just that is also helpful (even without
> comments). 

I have reviewed the draft.  I have some comments.

  - It seems strange that the intro does not offer a sketch and critique
    of 3517 given that 5681, rate halving and PRR are all sketched and
    the natural question of "well, how does 3517 related?" comes to
    mind.

  - And, this is even more problematic when you start making comparisons
    to 3517 in the 5th paragraph of the intro.

  - In general, I think you could intuitively frame these algorithms
    better in non-normative words.  There is clear similarities and
    differences in the strategies that even if there are muddled (e.g.,
    how many segments get sent in the RTT following recovery, or whether
    those segments are spread out over the RTT or bunched up together,
    or how fast segments are sent when they are sent (as distinct from
    how many are sent)).

  - It'd be more useful to cite Van's SIGCOMM paper than to cite Van.

  - It struck me as odd that you noted 3517 as non-conservative.  I
    think that is wrong.  But, after reading the entire document I
    believe I understand what you mean.  

    And, in fairness I must have been reading the intro too quickly
    because you in fact define it there, but I missed the subtle shit
    you have introduced.  In particular, you say:

      [...] packet conservation principle: segments delivered to the
      receiver are used to as the clock to trigger sending the same
      number of segments back into the network.

    However, the SIGCOMM 88 paper is what is in my head:

      By `conservation of packets' we mean that for a connection `in
      equilibrium', i.e., running stably with a full window of data in
      transit, the packet flow is what a physicist would call
      `conservative': A new packet isn't put into the network until an
      old packet leaves.

    Being "delivered to the receiver" is only one way a packet can leave
    the network.  RFC 3517 is packet conserving assuming (a) one admits
    there is another way packets can leave the network and (b) its
    judgment of losses is reasonable.  This latter *can* be unreasonable
    if the path has a high degree of reordering.  In this case the
    estimate produced by IsLost() can be wrong and RFC 3517 will in fact
    add packets to the network before previous versions have left the
    network.  

    That said, while I know of empirical measurements that suggest one
    can find such paths, I know of none that shows this sort of
    reordering to be common.  So, I think the assumption holds.  And, I
    think RFC 3517 is packet conserving.

    I think at the very least you should be very clear in calling out
    your definition of "packet conservation" in the intro---and note
    that it is not the only interpretation.  The document is a lot
    easier to understand if one has this bit in mind.  Otherwise, it
    comes off as confused.

  - In definitions you should remind us of the snd.una definition since
    you use it in many of your definitions.

  - In 3.1 you should cite Limited Transmit.

  - There is also a 3517bis which should pop out any day now as RFC
    6675.  You should at least note this.

    And, because it is a little different than 3517 in your examples
    because loss recovery can now be triggered on the first dupack if
    there is enough SACKed data in the incoming ACK to indicate that
    three segments have left the network (either lost or delivered).
    So, e.g., in your second example the ACK of 15 would trigger the 7R
    burst.

    I don't think you need to work things in terms of RFC 6675 because
    your measurements are in terms of RFC 3517.  But, at least a note to
    help folks follow the relationship seems worthwhile.

  - On page 8 you note that your *measurements* suggest something.  But,
    later on it seems clear that the measurements show something.  I
    suggest cleaning this up.

  - I find this business about pipe being a lousy estimate on page 10 to
    be pretty dubious.

    I understand your point that errors in the estimate are spread
    across the RTT.  That is even nice.

    But, there is no evidence (provided; and I am aware of none) that
    pipe is in general a bad estimate.  And, even if there is some
    reordering issues we have defined a way to get around that (RFC
    4653) (which probably boils down to something like rate halving in
    one of the two variants).  So, at least some mention of this would
    seem germane and I'd suggest just toning down the whole thing a bit
    given that there is no reason to think in most cases pipe is busted.

    (Or, point to evidence that says pipe is busted.  But, if it is then
    we should also be thinking of adjusting the dupack threshold.)

  - In the second paragraph of section 5 you mention 'production use'.
    I get it after reading a couple of paragraphs ahead.  You might move
    the notion that you ran all this in Google production servers to the
    front of the section.

  - You note that for 3517 that in 32% of the cases pipe is less than
    ssthresh when entering loss recovery.  I assume this means the
    ssthresh that is set upon entering, right?  You might make this more
    clear.

So, in general I think this document is fine.  It needs cleaned up,
IMO.  But, the mechanism is nice.

I do wonder why it is going experimental.  That seems too cautious to
me.  It seems these things are no more aggressive than 3517 and that is
standards track and so why should this spin at experimental?  What is
the experiment here?  What are we concerned about?  I say let it go as
standards track.

allman

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 25 Aug 2012 10:03:57 -0700

Hi Mark,

> the experiment here?  What are we concerned about?  I say let it go as
I agree with the logic appears to be conservative enough, but I'm not very
sure if it's a enough reason to publish a tcp's CC logic as a standard.
I'm wondering how to justify this.

Thanks,
--
Yoshifumi

---

From: Ethan Blanton <[email-masked]>
Date: Sat, 25 Aug 2012 18:26:37 -0400

> I'm wondering how to justify this.

As I read 5681, any scheme which is at least as conservative as 5681
is implicitly allowable.  I have no problem, in general, with allowing
any behavior at least as conservative as a standards track algorithm
to go standards track; this suggests that any penalty paid for using
the algorithm will be paid by the host using the algorithm, which
seems OK to me.

As Mark asks, what is the experiment?  If WG consensus is that an
algorithm is OK out in the wild, standards track is the right target.

(Disclaimer: I haven't yet read the draft.)

Ethan

---

From: Pasi Sarolahti <[email-masked]>
Date: Sun, 26 Aug 2012 23:02:28 +0300

Hi Mark,

Thanks for the detailed review.

> the experiment here?  What are we concerned about?  I say let it go as

Fair questions. I checked the minutes from IETF-81, where this was adopted specifically as experimental according to the minutes. I wasn't there at the time, so I don't know if the PS vs. Exp issue was discussed at all, but no one seems to have questioned the experimental status until now.

I wonder about the process issues related to changing the status at this point. People who have read the draft earlier may have done so with the mindset of evaluating an experimental document. If we wanted to change the intended status now, we might need a separate consensus call to verify that the rough consensus supports it.

- Pasi

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 26 Aug 2012 22:31:57 +0200

> > me.  It seems these things are no more aggressive than 3517 
> and that 
> > is standards track and so why should this spin at 
> experimental?  What 
> > is the experiment here?  What are we concerned about?  I 
> say let it go 
> > as standards track.
> 
> Fair questions. I checked the minutes from IETF-81, where 
> this was adopted specifically as experimental according to 
> the minutes. I wasn't there at the time, so I don't know if 
> the PS vs. Exp issue was discussed at all, but no one seems 
> to have questioned the experimental status until now.

I don't recall any discussion on a status other than experimental.
 
> I wonder about the process issues related to changing the 
> status at this point. People who have read the draft earlier 
> may have done so with the mindset of evaluating an 
> experimental document. If we wanted to change the intended 
> status now, we might need a separate consensus call to verify 
> that the rough consensus supports it.

Yes, I think that this would require more feedback from the community.

Michael

---

From: Michael Welzl <[email-masked]>
Date: Sun, 26 Aug 2012 22:49:31 +0200

> Yes, I think that this would require more feedback from the community.

I read it, with experimental in mind, but I'd support seeing this on  
standards track. I agree with Mark's points.

Cheers,
Michael

---

From: Mark Allman <[email-masked]>
Date: Mon, 27 Aug 2012 10:42:00 -0400

> > I do wonder why it is going experimental.  That seems too cautious
> > to me.  It seems these things are no more aggressive than 3517 and
> > that is standards track and so why should this spin at experimental?
> > What is the experiment here?  What are we concerned about?  I say
> > let it go as standards track.
>
> I agree with the logic appears to be conservative enough, but I'm not
> very sure if it's a enough reason to publish a tcp's CC logic as a
> standard.  I'm wondering how to justify this.

It sounds to me like this path to experimental was chosen by default.
I.e., without thinking about status very hard we can always start at
experimental.  So, lets think about it for a few minutes.

I can argue both ways on technical grounds.

On the one hand, PRR does not set the amount of transmission rate
reduction, it merely sets the sending pattern based on an externally
provided reduction.  So, if the algorithm is fed a reduction of 50% (a
la current standard TCP) then it will send at most 50% of the previous
flight size in the RTT following loss detection.  This is absolutely
consistent with the spirit of TCP congestion control (RFCs 2914, 5681,
3517, 6675 (== 3517bis)).  This reading of things says that even if we
call it 'experimental' it is consistent with the "or more conservative"
notions allowed by the various RFCs and so PRR is implicitly allowed as
standards track regardless of what label you put on it.  So, we might as
well label it accurately.

On the other hand, one could argue that the *pattern* of sending is
different under PRR and hence this makes it different enough as to not
be covered under the argument above.  PRR is at once more conservative
and more aggressive than current standards track schemes (a point which
could be better made in the PRR document, IMHO).  Consider the first
example in the draft whereby all schemes send the same number of
packets.  PRR is more conservative in the rate it sends those packets
into the network.  The rate is roughly half that before loss detection.
However, PRR is also more aggressive in that it starts this sending
right away whereas 3517(bis) leaves the network idle for a bit (1/2 RTT)
before sending.  So, we could view PRR as more aggressive in that it
sends sooner.

So, I think one can argue either side here.  My own hit is that the
first order is the reduction factor (half for PRR just as for earlier
standard CC schemes) and the second order is the pattern.  The pattern
might be important in some cases and PRR might be a better pattern than
3517 or rate halving.  But, ultimately for safety I think the magnitude
of the MD is the important thing.  So, of the two arguments above, I buy
the first---i.e., that PRR is consistent with the standards and so using
it could not be called non-standard and so we should just label it
accurately as standards track.

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 27 Aug 2012 10:43:13 -0400

> I wonder about the process issues related to changing the status at
> this point.

The process is that y'all say someone has suggested the status should be
standards track and you want to know what the WG thinks of that.  This
document has not left the WG.  I have not seen any declaration that it
passed WGLC.  It is within this WG's purview to consider this question.

allman

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 27 Aug 2012 13:47:34 -0400

> passed WGLC.  It is within this WG's purview to consider this question.

As AD, that's correct :).

Personally, I wouldn't have any real problem with PS based on what's
known at this point.

-- 
Wes Eddy
MTI Systems

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 27 Aug 2012 21:27:50 +0300

> passed WGLC.  It is within this WG's purview to consider this question.

Yep. That said, I hope more people can voice their opinions on this.

One question, though: the document gives two variants of the algorithm. If we go for standards track, wouldn't it be better to clearly recommend one of them? The current advise in conclusions:

   "At this time we see no reason not to test and deploy PRR-SSRB on a
   large scale.  Implementers worried about any potential impact of
   raising the window during recovery may want to optionally support
   PRR-CRB (which is actually simpler to implement) for comparison
   studies."

sounds like there is something to be tested still.

- Pasi

---

From: Matt Mathis <[email-masked]>
Date: Mon, 27 Aug 2012 12:16:11 -0700

Sorry for the long radio silence here.

The only reason to bother with standards track is if there is a need
to compel reluctant manufacturers to implement and deploy it.
Customers can then write in their requests for quotes specifications
such as "must support SACK (RFC 2018), and then suddenly the lack of
SACK support becomes a high priority issue for some large manufacture
who shall remain nameless.

Back in the old days (before 1990) RFC meant "request for comments"
and there was no such concept as "standards track". We wrote down our
ideas, and if they were valuable, they became part of the installed
base.   For PRR this has already come to pass for the installed base
that is most important to me.

If management at Apple or Microsoft think PRR isn't worth the effort,
then making PRR a standard will permit their customers to influence
their priorities.   Given the extent to which PRR is an across the
board win, I really don't think this is required.  (However, I could
change my mind if a TCP engineer at one of the above companies
indicate that they are getting pushback from their management.)

Finally there are some details in PRR that are effected by Laminar.  I
would rather not go to the effort of fixing the current draft to make
it a proper normative PS, but not totally correct.  (Hint: Yoshifumi
Nishida's "off by one" comment reflects the difference between pipe
and total_pipe).

So here is what I was planning to do:  Push out the current document
as experimental, and then after Laminar is further along, generate a
normative respecification using Laminar state variables (probably as
one section of a larger doc, but that remains TBD).

Does that make sense?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Mon, Aug 27, 2012 at 7:43 AM, Mark Allman <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Mark Allman <[email-masked]>
Date: Mon, 27 Aug 2012 15:18:02 -0400

> Yep. That said, I hope more people can voice their opinions on this.

Agreed.

> One question, though: the document gives two variants of the
> algorithm. If we go for standards track, wouldn't it be better to
> clearly recommend one of them? The current advise in conclusions:
> 

I don't think the question should be: Is there anything more to learn?
If that was the question we'd spin everything at experimental forever.

Both variants are at most as conservative as current standards.  There
is a fine tradition in any number of the TCP docs of giving implementers
choices.  I view this document as doing just that.  And, in this case,
both choices are conservative in my view.

allman