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

From: Qiaobing Xie <[email-masked]>
Date: Wed, 21 Mar 2001 23:52:25 -0600

Jon,

I see your point here and I think you are right. 

Taking your point into consideration, I'd say that the Definition #1 in
Armando's original email is the ONLY correct behavior that the receiver
MUST stick with. The alternative interpretation (Defn #2) is wrong in
that it in effect dishonors the service reliability promised by the
sender to its upper layer application. 

I am thinking that the 'k' retransmission request is a "hard request".
In other words, when a message requiring 'k' retransmissions is passed
down from the application and accepted by the SCTP sender, the SCTP
layer has in effect made a service contract to attempt 'k'
retransmissions before giving up the effort of delivering this message
to the receiving application. Armando's Definition #2 will make the
U-SCTP service incapable of honoring this "hard" contract.

-Qiaobing

Jon Berger wrote:
> 
> Qiaobing,
> 
> I'm not sure I agree with your statement that it is entirely an
> implementation decision.  Last week you were suggesting that setting the
> number of retransmissions in U-SCTP to a large number was pretty much
> equivalent to reliable delivery.  Now you are saying that this depends on
> the receiver's implementation.
> 
> I agree with Armando that this is an area of concern that needs to be
> explicitly addressed in the draft.  (I admit that when I read it, Definition
> 1 was what I envisaged.)
> 
> Jon
> 
> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: 21 March 2001 06:41
> To: Armando L. Caro Jr.
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] ambiguity in U-SCTP draft
> 
> 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
> 
> _______________________________________________
> 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: Phillip Conrad <[email-masked]>
Date: Thu, 22 Mar 2001 10:03:56 -0500

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.

The benefits of partial reliabiltiy can be looked at from two perspectives: 
why PR would be preferred to full reliability (R), or why PR would be 
preferred to no reliability (unreliable, single best-effort transmission, 
or "U").  I would argue that either perspective leads us to conclude that 
definition #2 is superior.

PR vs R:  The main benefit of a relaxation in the strict delivery 
requirement for a packet is the reduction in delay that pertains to 
subsequent packets that are no longer delayed by waiting for 
predecessors.  If we adopt definition #1, the receiver must delay delivery 
of subsequent packets based on waiting for packets that may or may not ever 
arrive.    However, if we adopt definition #2, then we have the desirable 
property that packets that are *available* at the receiver are never 
delayed waiting around for packets that are arguable losable (otherwise we 
would have sent them as fully reliable in the first place.)

PR vs. U:  The main benefit of sending something with a number of 
transmits > 1, while still allowing it to be dropped eventually, is that we 
can take advantage of any extra time for retransmits that we might have as 
a result of, for example, the receiving transport layer building up some 
packets in the delivery queue.     If the application gets "busy" and 
doesn't read packets very fast for some period of time, then a service that 
will try to keep retransmitting for a while, but perhaps eventually give 
up, will be able to take advantage of this to offer higher reliability over 
lossy networks, WITHOUT increasing delay during times when the application 
is starving for data.

(As an aside: this last point is the one of the key ideas that I explored 
in my Ph.D. dissertation, which includes algorithms for implementing this 
idea in the context of synchronization of objects in streaming multimedia 
documents... those with insatiable curiosity can check out chapters 2 and 6 
of the thesis cited above.)

I've argued that defn #2 is more useful... easier to implement comes from 
the fact that the rule is simple:   when the application requests data:

     if (you've got some data on one of your streams that
        matches the next sequence number expected)
           go  ahead and deliver that.
     else
          check your unreliable streams, and...
          if you have any packets buffered,
              ack* all the ones on that stream that are missing
              deliver the lowest numbered one (w.r.t. TSN)

* it may or may not be useful to mark this ack in some way so that the 
sender can
distinguish an ack of delivered data from an ack of data that was "declared 
lost".

This algorithm was explored in more detail in my dissertation... I'm 
currently preparing a conference paper on that topic also.

Qiaobing is correct that Armando's definition #2  means that the # of 
retransmissions is no longer a "hard" guarantee, but an advisory one in 
some sense... it tells the sender how long to keep trying before giving 
up.   Under defn #2, setting it to a high number (e.g. 16 or 256) means: 
keep trying until the receiver gives up on receiving this packet.   This is
more useful than having  high number be equivalent to reliable delivery, 
since SCTP already provides a mechanism
for reliable delivery.

That, one might ask, what is the benefit of setting the numTransmits to any 
value like 2, or 3, instead of always using 256?  Here, the motivation is 
conservation of bandwidth... by setting numTransmits to 2, we are saying: 
"this data is important enough to attempt *one* retransmission, but after 
that, give up, and let some other packet use the bandwidth.

I hope these ideas are helpful.     As I've indicated, my preference is for 
definition #2.  However, it may be that  between now and the London IETF we 
need to perhaps simulate or implement both definitions and get some real 
data on how the two perform before we are ready to standardize on one or 
the other.

Thanks,
Phill Conrad

At 11:52 PM 3/21/2001 -0600, Qiaobing Xie wrote:
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

---