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

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

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

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Fri, 30 Mar 2001 10:09:56 -0600

Phillip:

I'd consider both definitions as useful depending on the context. 
#1 let's the transmitter control PR, with #2 PR is under the control of the
receiver. #2 could furthermore be extended to let the receiver specify how
long it would be prepared to wait for the next in-sequence chunk.
#1 seems useful in cases the application has a defined time-out waiting for
a response (provided you can map time to number of retransmissions) like in
call control signaling.
If #2 is used the max retransmission parameter cannot be used to distinguish
R from PR.

Just my $0.02

Klaus

> -----Original Message-----
> From: Phillip Conrad [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 10:04 AM
> To: [email-masked]
> Cc: Qiaobing Xie; Armando L. Caro Jr.; [email-masked];
> [email-masked]
> Subject: Re: [Tsvwg] ambiguity in U-SCTP draft
> 
> 
> 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:
> >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
-----------------------------------------------------------------------
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

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