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

From: Qiaobing Xie <[email-masked]>
Date: Wed, 21 Mar 2001 00:40:53 -0600

Armando,

This's really an implementation choice on the receiver side. Either
definition will work just fine, with slightly different performance
characteristics - Definition 1 trades delay for reduced message loss,
while Definition 2 trades loss for reduced delay. 

-Qiaobing

"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

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Mar 2001 08:40:13 -0600

> receiver determines it needs to move forward and give up on the lost

I am not sure how you could ever get from our converstation definition
2... if it is not clear it will be made clear in the next U-SCTP
specification. A receiver SHOULD wait for the F-TSN before releasing
any out-of-order U-SCTP data. If this wording is not in the
draft it will break the contract that exists between the sender
and the receiver.

I understand your thoughts for multi-media... but this is not
the primary intent of the draft. If someone wanted to use it
for multi-media then send UN-Ordered data and let the upper
layer put RTP or some such inside the SCTP data packet. Then it
can do what EVER it likes for jitter buffer etc...

Of course this is a receiver side behavior anyway not something
that effects the bits on the wire but the actual internal API
of the reciever... maybe this is why we did not get it into
the document yet :0

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---