Subject: [Tsvwg] PRSTCP-00

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 May 2002 04:05:37 -0500

Randall,

Two comments and a question:

1) My compliments on an excellent draft.

2) Page 11:

   "The data sender MUST then perform the following additional steps:"

   And

   "C2) Try to further advance..."

   C2) shows the Adv.Ack.Pt advancing over gap-acked TSNs.  What
   happens if the peer is in the process of a renege on those
   gap-acked TSNs?  When the SACK reneging on the gap-acked TSNs
   arrives, the reneged TSNs will be behind the Adv.Ack.Pt.  Also,
   when the peer receives the FORWARD TSN, it will be forced to
   update its cumulative ack point beyond the reneged TSNs.  These
   reneged TSN might be fully reliable TSNs which have now been
   dropped.

   Considering reneging, I don't think that the PRSCTP sender should
   advance the Adv.Ack.Pt past gap-acked TSNs.  It should wait until
   those TSNs are cumulatively acked (no longer renegable -- is that
   a word?) before advancing the Adv.Ack.Pt further.

Q) I understand that it is only one possible PRSCTP user interface
   methodology, but what is the use of a transport-based "timed
   reliability"?  I agree that application timed reliability (from
   transport user to transport user) might be useful, but this
   concept of "timed reliability" does not take into account the
   amount of time that data waits queued in the peer's receive queue
   before being delivered to the application.  As such, it only
   really times the amount of time in the send and retransmission
   queues which is related to transmit congestion only: when an
   association becomes congested, data with the shortest lifetimes
   will be dropped.  It also appears to mean that data with the
   longer lifetimes have higher priority in times of congestion.
   With a mix of partial and full reliability data, all the partial
   data will be dropped in times of congestion and all the full
   reliability data will queue indefinitely waiting for the congestion
   to abate.  What has this to do with "reliability"?  It appears
   more reminicent of the Unix "nice" command.  Unfortunately,
   setting the priority of a message by setting its lifetime
   parameter would require a deep understanding of the queueing
   model and the traffic distribution of all other messages in all
   other streams.  It seems unlikely that a useful value could be
   determined except for the most narrow of applications.

   Is there a good real-world example of where transport-based
   "timed reliability" would be most useful?  The previous concept
   of limiting the number of retransmissions appeared far more
   useful for such things as RTP/SCTP (e.g. number of retransmission
   set to zero).

Well, suppose thats really a bunch of comments and a bunch of
questiosns...

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 31 May 2002 17:34:31 -0400 (EDT)

> 1) My compliments on an excellent draft.

To be honest, I still have to read the latest version :-)

>    a word?) before advancing the Adv.Ack.Pt further.

Yes, I agree with you. There shouldn't be a change in performance
either. The receiver sees the cum ack change, moves it even further
if possible, and conveys the info to the sender via a SACK.

>    reliability"?

The idea is that the application has a better understanding of time
than the number of retransmissions. It doesn't mean too much to an
application that a chunk will be retransmitted x number of times. How does
the application know what is an appropriate lifetime? However, time _is_
meaningful to an application.

>  I agree that application timed reliability (from
>    before being delivered to the application.

No it doesn't, but does it matter? If the receiving application isn't
reading data fast enough, that is a different issue... The transport did
its job.

>    "timed reliability" would be most useful?

I don't know much about iSCSI, but my understanding is that the
application layer has its own retransmission mechanisms based on timers.
Using the k-rtx model, iSCSI doesn't know how many retransmissions is
appropriate to avoid going over their own retransmission timers. Hence,
the timed reliability is very useful for them to avoid having conflicting
retransmissions at the application and transport layers. They can simply
set the timed reliability to something below their own retransmission
timer.

(But like I said, I don't know iSCSI. So, I may be way off here...)

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 May 2002 20:42:57 -0500

Qiaobing,

Huh?  Where is this in RFC 2960?  I would surely think that an SCTP
receiver must reneg to thwart a tear-drop attack.

--brian

On Fri, 31 May 2002, Qiaobing Xie wrote:

> > Unless the renege is being misused or abused, there is no change that
> > the above scenario can happen. Remember that the renege is only used
> > when the receiver runs out of buffer when it is in the middle of
> > re-assembling a fragmented message *and* not all fragments are received
> > *and* the arrived ones are out of order. So when a TSN is reneged, it
> > must be true that there is at least another missing TSN that is earlier
> > than the reneged TSN *and* belongs to the same message. Since these two
> > TSNs belong to the same message, on the sender side, it would be either
> > that the missing TSN will stop the advance of Adv.Ack.Pt, or the reneged
> > TSN will be "dropped" as well (since the sender should never "drop" half
> > a message). Either case, there will be problem.
>                                    ^^^^^^^^^^^^^
>                               ...will be *no* problem...