[tsvwg] comments to RFC3758

["Karen E. Egede Nielsen" <[e-mail]>]

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