Subject: [tsvwg] comments to RFC3758

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Sun, 20 Jul 2014 16:34:06 +0200

HI,

Having studied RFC3758 in a little detail (in connection with
draft-ietf-tsvwg-sctp-prpolicies)

then there is an issue with the present document text, which I think
deserves

clarification. Or at least I am not sure about how to interpret the text.

I hope that the wg may help guide on what the right
clarification/understanding is.

The issue relate to handling of the flightsize and the calculated

receiver window rwnd when abandoning a message and/or receiving a (S)ACK of
the Forward TSN, respectively.

The rule A2) (section 3.5) says:

       When a data chunk is "abandoned", the sender MUST treat the data
       chunk as being finally acked and no longer outstanding.

This MUST clearly must not be taken literally as it indeed is being
disclaimed by a number of following

recommendations given:

Section 3,5, A2)

       The sender MUST NOT credit an "abandoned" data chunk to the
       partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2],
       and MUST NOT advance the cwnd based on this "abandoned" data
       chunk.

Section 3,5 F5)

       If the decision to "abandon" a chunk is made, no matter how such
       a decision is made, the appropriate congestion adjustment MUST be
       made as specified in RFC 2960 if the chunk would have been marked
       for retransmission later (e.g., either by T3-Timeout or by Fast
       Retransmit).

What I would have like to see, however, would be some disclaimers and/or
more explicit descriptions of what

to do/or not do with with the flight-size and the calculated rwnd when a
message is abandoned.

Here there are clearly 2 options in terms of how to interpret the “MUST
treat as no longer outstanding”:

>From a conservative congestion control perspective then I would opt for
that the data chunk should not be taken out of the flightsize and sliding
window protocol variables before a SACK of the TSN/respectively of the
FORWARD TSN has been received (conditional to F5).

Alternatively if the intend of RFC3758 is to have an abandoned TSN be taken
out of flight-size immediately, then I first and foremost think that

the implication via-a-vis congestion control should be explicitly described
in the document (if the message is in-flight one is in fact overshooting
the cwnd) and secondly then for the sender not to send outside of rwnd, one
would then want to more stringently specify that a delayed FORWARD TSN MUST
be sent no later than with the first data chunk after the abandon of a
message. This may be the intend of C3) and F2) of the document, but it is
not written explicitly.

Thanks in advance.

BR, Karen

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 20 Jul 2014 15:38:23 -0600

Karen,

Please see comments below...

Karen E. Egede Nielsen wrote:         (Sun, 20 Jul 2014 16:34:06)

(1)
>    chunk as being finally acked and no longer outstanding.

This pertains to acknowledgement only: the packet is acked; plain
and simple.  Do not read more into it than that.

The other passages are explicit on how to treat congestion.

(2)
>    and MUST NOT advance the cwnd based on this "abandoned" data chunk.

(3)
>    If the decision to "abandon" a chunk is made, no matter how such a
>    decision is made, the appropriate congestion adjustment MUST be

>    What I would have like to see, however, would be some disclaimers
>    and/or more explicit descriptions of what to do/or not do with with
>    the flight-size and the calculated rwnd when a message is
>    abandoned.

I think all three passages are quite clear.

>    Here there are clearly 2 options in terms of how to interpret the
>    MUST treat as no longer outstandingâ:
> 
>    From a conservative congestion control perspective then I would opt
>    for that the data chunk should not be taken out of the flightsize
>    and sliding window protocol variables before a SACK of the
>    TSN/respectively of the FORWARD TSN has been received (conditional
>    to F5).

That is what is said in (3) above.

>    Alternatively if the intend of RFC3758 is to have an abandoned TSN
>    be taken out of flight-size immediately, then I first and foremost
>    think that the implication via-a-vis congestion control should be
>    explicitly described in the document (if the message is in-flight
>    one is in fact overshooting the cwnd) and secondly then for the
>    sender not to send outside of rwnd, one would then want to more
>    stringently specify that a delayed FORWARD TSN MUST be sent no
>    later than with the first data chunk after the abandon of a
>    message. This may be the intend of C3) and F2) of the document, but
>    it is not written explicitly.

No, (2) says it cannot contribute to partially acked bytes and (3) says
it cannot be removed from flight size until a T3-timeout or
acknowledgement.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 21 Jul 2014 01:03:59 +0200

Hi,

> This pertains to acknowledgement only: the packet is acked; plain and
> simple.  Do not read more into it than that.
>
> >    MUST treat as no longer outstanding :
> >
> No, (2) says it cannot contribute to partially acked bytes and (3) says it
> cannot
> be removed from flight size until a T3-timeout or acknowledgement.
>
[Karen]  I cannot see that 3 says this. Such an interpretation of (3)
presumes that
a message is only abandoned at a T3 or when marked for fast retransmission.
Furthermore 3 speaks
about congestion control adjustments not about inflight or rwnd.

BR, Karen

The document does not presume that

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 20 Jul 2014 22:54:37 -0600

Karen,

Karen E. Egede Nielsen wrote:           (Mon, 21 Jul 2014 01:03:59)
> presumes that a message is only abandoned at a T3 or when marked for
> fast retransmission.  Furthermore 3 speaks about congestion control
> adjustments not about inflight or rwnd.
> 
> BR, Karen
> 

If "the chunk would have been marked for retransmission later", then it
would have been considered in flight had it not been "abandoned".
Therefore, (3) effectively says that the abandoned chunk must continue
to be considered in flight for as long as it would have been had it not
been abandoned, which would be until the next T3-expiry or an ack.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/