Subject: [tsvwg] Mirja Kühlewind's No Objection on draft-ietf-tsvwg-rfc4960-errata-06: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 02 Jul 2018 06:42:10 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tsvwg-rfc4960-errata-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) sec 3.27.2:
" o  When the endpoint does not transmit data on a given transport
      address, the cwnd of the transport address SHOULD be adjusted to
      max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the
      ssthresh of the transport address SHOULD be adjusted to the cwnd."
This part is still unclear to me. What does adjust "per RTO mean"? I guess it
is sufficient to adjust it once after the first RTO without data, no? Also I
assume ssthresh is set after the cwnd adjustment?

2) sec 3.28.2
"An SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data. When the window opens
   up, an SCTP receiver SHOULD send additional SACK chunks to update
   the window even if no new data is received. The receiver MUST avoid
   sending large bursts of window updates."
This is also not super well specified now. What is a large burst?
I would rather like to see something like "The receiver MUST not send more then
one window update per RTT."

3) 3.31.
Would it make sense to then use a different variable, e.g. cwnd_temp or
max_send_limit, and not cwnd...?

4) Text changes in sec 3.35.2. are kind of unclear. I assume the new text
should be added at the end of the old text sections...?

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Jul 2018 07:51:31 +0200

> On 2. Jul 2018, at 15:42, Mirja Kühlewind <[email-masked]> wrote:
> 
Hi Mirja,

> assume ssthresh is set after the cwnd adjustment?
The idea is that you basically half the cwnd after each RTO until you
reach 4 * MTU. Then you stay at 4 * MTU. So you half it possibly multiple
times.

When the idle period ends, you can use slow start to the reach the old
cwnd. So ssthresh is set to cwnd before the initial adjustment.

I changed the 'New text' to

o  When the endpoint does not transmit data on a given transport
   address, the cwnd of the transport address SHOULD be adjusted to
   max(cwnd/2, 4*MTU) per RTO. Before the first cwnd adjustment, the
   ssthresh of the transport address SHOULD be set to the cwnd.
> one window update per RTT."
That would require a timer... You generate these SACKs when the receiving
application reads data. Assume the receive buffer is full with small
messages and the application starts the read messages at high speed.

There were stacks sending a window update SACK for each message delivered.
This is a large burst. Running a timer for sending these SACKs is a bit
of an overkill, I think. In FreeBSD, a SACK is only sent if at least
a quarter of the receive buffer is freed. This limits the burst to
4 SACKS which is in tune with the burst mitigation limit used for
SCTP packets containing user data. This is also more than one per RTT.
However, other implementations might do it differently and we wanted
to allow this.

If you think this is a critical thing, we can work out some strategy.
> max_send_limit, and not cwnd...?
If you would do that, then you have to explain when to use the new
variable instead of cwnd. I don't think this makes it easier...
> should be added at the end of the old text sections...?
Correct. It is actually a new sub section. I have added the new subsection
header to the "New text:". It reads now

7.2.5.  Change of Differentiated Services Code Points

   SCTP implementations MAY allow an application to configure the
   Differentiated Services Code Point (DSCP) used for sending packets.
   If a DSCP change might result in outgoing packets being queued in
   different queues, the congestion control parameters for all affected
   destination addresses MUST be reset to their initial values.

Best regards
Michael

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 9 Jul 2018 15:47:43 +0200

Hi Michael,

see below.

> Am 03.07.2018 um 07:51 schrieb Michael Tuexen <[email-masked]>:
> 

Thanks that resolved most of my confusion… The „per RTO“ could also be more clear. Was thinking about proposing something like „after each RTO if time that is idle“. However, not sure that is better and might just be me who was confused/didn’t read carefully.

> If you think this is a critical thing, we can work out some strategy.

Yes, to me it seems to make sense to at least implement some limit. Why don’t use just go for „MUST not send more than 4 window updates per RTT“ if that is what you do already anyway? 

> variable instead of cwnd. I don't think this makes it easier…

I still find the use of cwnd here confusing.

>   destination addresses MUST be reset to their initial values.

Thanks!
Mirja

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 10 Jul 2018 18:30:58 +0200

Hi Mirja,

see comments in-line.

Best regards
Michael

> On 9. Jul 2018, at 15:47, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Michael,
> 
> see below.
> 
what about using

o  While the endpoint does not transmit data on a given transport
   address, the cwnd of the transport address SHOULD be adjusted to
   max(cwnd/2, 4*MTU) once per RTO.
   Before the first cwnd adjustment, the ssthresh of the transport
   address SHOULD be set to the cwnd.

The term "idle" is used differently in the document. So I would like
to avoid it here.
> Yes, to me it seems to make sense to at least implement some limit. Why don’t use just go for „MUST not send more than 4 window updates per RTT“ if that is what you do already anyway? 
Since FreeBSD does not send more than 4 window updates per T. And T can be any positive number.
It is not tied to RTT.

What about 

The receiver MUST avoid sending a large number of window updates, in particular
large bursts of them.

I think this is a better description of the intention.
> I still find the use of cwnd here confusing.
We debated this a lot. The point is that you want to reduce cwnd temporarily,
not and other variable. So you would do something

      old_cwnd = cwnd
      if ((flightsize + Max.Burst*MTU) < cwnd)
          cwnd = flightsize + Max.Burst*MTU
      /* do what ever you want to do with cwnd */
      cwnd = old_cwnd

I guess this pattern is pretty well described with the current text. But
not with introducing a new variabel with the reduced value.