Re: [Tsvwg] u-sctp comments

[Randall Stewart <[e-mail]>]

Armando:

In general great comments... just a few quick comments
and I am sure Qiaobing may have more :)

"Armando L. Caro Jr." wrote:
> 
> Hi,
> 
> I have a few comments/suggestions about the unreliable data mode extension
> draft...
> 
> I think the draft should provide explicit detail about handling the T3-rtx
> timer when attempting to retransmit due to a timeout or a fast
> retransmit. Also, any data chunk which is marked as acked by exhausting
> the allowed number of retransmissions must not credit partial_bytes_acked.
> 
> I suggest the following changes:
> 
> Section 4.2.A2.B3
> "
>      B3) If the "Unrel.Trans.Count" is currently 0, the sender MUST NOT
>          retransmit the data chunk. Instead, the sender MUST mark the
>          data chunk as being finally acked.
> "
> changed to:
> "
>      B3) If the "Unrel.Trans.Count" is currently 0, the sender MUST NOT
>          retransmit the data chunk. Instead, the sender MUST mark the data
>          chunk as being forward acked and thus ineligible for crediting
>          partial_bytes_acked. In addition, the sender MUST no longer
>          consider the data chunk outstanding. The sender MUST stop the
>          T3-rtx timer if there are no more oustanding data
>          chunks. Otherwise, the sender MUST restart the T3-rtx timer.
> "

This looks good but I am not sure about the 

"mark the data chunk as being forward acked and thus..."


I understand what you mean, but is it clear for other readers .... :-)

> 
> The added text about the T3-rtx timer _could_ be inferred from the fact
> that the data chunk is no longer considered outstanding, but I think
> without explicitly mentioning it, implementations may overlook this subtle
> point. While testing the unreliable option in our ns-2 implementation, I
> have noticed that if this point is overlooked, a burst loss may suffer
> from a spurious timeout.
> 
> Section 4.2.A3
> "
>  A3) whenever the data sender receives a SACK from the data receiver,
>      it SHALL first process the SACK using the normal procedures as
>      defined in Section 6.2.1 of [RFC2960].
> "
> changed to:
> "
>  A3) whenever the data sender receives a SACK from the data receiver,
>      it SHALL first process the SACK using the normal procedures as
>      defined in Section 6.2.1 of [RFC2960], with the following
>      exception. Any data chunk marked as forward acked MUST not credit
>      partial_bytes_acked.
> "

This makes sense being hand and hand with the previous change..

> 
> Other suggestions....
> 
> Section 4.2 - "Unrel.Trans.Count" should be "Unrel.Retrans.Count"
> 

Yes, I think that is better..

> Section 4.2
> "
>    Note, if a TSN is indicated as missing by a SACK carrying gap reports
>    AND the TSN is earlier than the current "Advanced.Peer.Ack.Point", the
>    data sender MUST NOT take any action on this TSN, ...
> "
> should be:
> "
>    Note, if a TSN is indicated as missing by a SACK carrying gap reports
>    AND the TSN is earlier than or equal to the current
>    "Advanced.Peer.Ack.Point", the data sender MUST NOT take any action on
>    this TSN, ...
> "
> 
> I know as far as RFC2119 is concerned, SHALL = MUST. However, I find
> interchanging these words throughout the document somewhat
> confusing. Wouldn't it be better to simply pick one (say, MUST), and use
> it religiously throughout the document?


Hmm... I think we should change all SHALL to MUST ... I did not
realize we had any "SHALL's" in the document ... sigh...

R
> 
> Thanks,
> Armando
> 
> -----------------------------------------------------------------------
> Armando L. Caro Jr.                                  [e-mail]
> University of Delaware                   http://www.cis.udel.edu/~acaro
> -----------------------------------------------------------------------
> 
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[e-mail] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg