Subject: Re: [Tsvwg] ambiguity in U-SCTP draft

From: "Lyndon Ong" <[email-masked]>
Date: Tue, 20 Mar 2001 12:29:40 -0800

Hmm, Armando,

I would have picked definition 1, as there is nothing that tells the receiver that they can resume delivery on that stream until the sender advances the TSN.  

BTW, if you do it the other way might you not have a potential for interpreting mis-sequencing as a lost chunk?

Cheers,

Lyndon

--

On Tue, 20 Mar 2001 14:21:14   Armando L. Caro Jr. wrote:
>After the tsvwg session monday, I discussed with Randy and La Monte the
>issue I pointed out about unreliable, ordered data suffering
>unnecessary delays due to SOME head-of-line blocking. They temporarily
>convinced me that it was a non-issue. After further thinking and a
>re-read of the draft, I realized that there is some ambiguity in the draft
>and depending on the interpretation, it could still be an issue.
>
>The draft is not clear on how the receiver should handle reordering. There
>are two possible definitions of partial reliability and each implies a
>different way of handling reordering. Let me explain the two possible
>definitions.
>
>Definition 1: A lost partially reliable chunk is retransmitted at most 'k'
>times.  Hence, the receiver MUST wait for a FORWARD TSN from the sender
>before determing that the a given lost chunk should be given up on. If the
>recever needs to deliver data to the application and the lost chunk has
>still not arrived, the receiver cannot give up on the lost chunk until all
>'k' restransmits have been used.
>
>Definition 2: A lost partially reliable chunk continues to be
>retransmitted until either the receiving end needs to deliver
>new data to the application OR the 'k' retransmit value is reached.
>In other words, if the receiver needs to deliver data to the application
>and the lost chunk still hasn't arrived, the receiver gives up on it and
>moves on.
>
>To me, the draft implies Definition 1. That is the reason I originally had
>an issue with zero-retransmit, ordered delivery. In this case, even if the
>packet should never be retransmitted, there is unnecessary delay.
>
>After my discussion with Randy and La Monte, I realized that the intended
>definition in the draft was in fact Definition 2. My feeling is that
>Definition 2 is the better way to go, but this may need more research.
>If Definition 2 is used, an infinite 'k' value does not mean full
>reliability. Instead, it simply means continue retransmitting until the
>receiver determines it needs to move forward and give up on the lost
>chunk.
>
>Additionally... From what I understood (and I may be wrong), the IP
>Storage people prefer Definition 1 for their needs.
>
>Comments?
>
>-----------------------------------------------------------------------
>Armando L. Caro Jr.                                  [email-masked]
>University of Delaware                   http://www.cis.udel.edu/~acaro
>-----------------------------------------------------------------------
>
>
>
>
>
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 20 Mar 2001 15:03:28 -0600

It was not my intent to advocate one defn or the other

The difference between these two definitions is not visible on the wire
so it is out-of-scope for the IETF.

The difference is really applies only to semantics at the application
layer.  This difference is important, but effects things like
API's--it has no effect on the protocol itself.