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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Phillip Conrad <[email-masked]>
Date: Thu, 22 Mar 2001 11:01:31 -0500

At 03:22 PM 3/22/2001 +0000, Lloyd Wood wrote:
> > http://www.cis.udel.edu/~conrad/thesis  :-) )
>Returns 404 not found.

Sorry: should be http://www.cis.udel.edu/~pconrad/thesis

Thanks, Lloyd, for pointing this out.

Phill Conrad
Asst. Professor, Temple University CIS Dept

[email-masked], [email-masked]
http://www.cis.temple.edu/~conrad     (That's where I'm ~conrad as opposed 
to ~pconrad ).

At 10:03 AM 3/22/2001 -0500, Phillip Conrad wrote:
>Qiaobing,
>     Having spent considerable time working with partially reliable 
> services over the last 4 years (see 
> http://www.cis.udel.edu/~conrad/thesis  :-) ) I would respectfully, but 
> rather emphatically raise some concern about  your conclusion below.   I 
> would argue that definition #2 is far more useful, far more clear, and 
> far easier to implement.
>...

---

---

From: Phillip Conrad <[email-masked]>
Date: Fri, 30 Mar 2001 11:23:11 -0500

At 10:09 AM 3/30/2001 -0600, Klaus Gradischnig wrote:
>Phillip:
>
>I'd consider both definitions as useful depending on the context.

Agreed... the bottom line is that they represent two different services to 
the user.   After some private discussions with Randall and Qiaobing, 
however, I've come to the conclusion that it is better to go forward with 
defn #1.

>BTW, the link to the thesis does not work for me.

The corrected link should be: http://www.cis.udel.edu/~pconrad/thesis
(I forgot the "p" the first time, since I am "pconrad" at UDel, but 
"conrad" at Temple.)

Thanks,
Phill Conrad

---