Subject: Re: [Tsvwg] PRSTCP-00

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Jun 2002 18:43:39 -0500

Randall,

Could you take another look at this one?  Moving the FORWARD TSN
along on the basis of a gap ack doesn't appear to be a good idea.
When a subsequent SACK could reneg (or truncate) the gap ack
resulting in the loss of a non-abandonned (even reliable) TSN.

--brian

On Thu, 30 May 2002, Brian F. G. Bidulock wrote:

> 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.
> 

[snip]

-- 
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: Qiaobing Xie <[email-masked]>
Date: Fri, 31 May 2002 18:03:20 -0500

Hi, Brian,

Since I was the one who formulated these steps. I will try to answer
your questions.

"Brian F. G. Bidulock" wrote:
...
>    reneged TSN might be fully reliable TSNs which have now been

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.

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

ditto.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Thu, 30 May 2002 07:34:54 -0500

> 1) My compliments on an excellent draft.

Thanks... this was not only my work .. but the excellent 
ideas and help of my co-authors as well... 

>    reneged TSN might be fully reliable TSNs which have now been

Hmm... I had not thought in detail on this case...

Now so I send

Last SACK
cum-ack=90
Gap=92-94
Gap=96-99

and I now (as the sender) want
to skip to 101..
FWD-TSN(101)------->

                   but in the mean time my peer is doing
                      <----SACK(90) ... NO GAPS..

If I do the above (as the current draft states) when the
SACK arrives the SACK is the SAME point as the CUM-ACK... so
It is not old or behind... I don't strike anything... and I would
in theory go to put a mark on the 92-94 and the 96-99 .. but they
are already marked as being skipped...

Hmmm... I am not sure I see a problem... what I think would
happen is that we would see 90, try to advance the cum-ack
and once again generate a 

FWD-TSN(101)-------------> 

in response to the SACK(90)...

Am I missing something?

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

I am not sure why.. maybe I miss something? can you explain?

> 
> 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

True... if the peer is NOT READING ... this time is not
accounted for...

>    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.
> 

I don't know if I agree here... I am not strongly married to
this particular service but I do think it is useful. I can see
sending a message that is going to be useless in 4 seconds from
the time I send it.. so unless I get it ACK'd by the
peer there is NO chance the peer can use it..

If the peer is not reading and I have this timelness constraint
I see this as more of a bug in the reader than a issue with
it not reading...

I think there are quite a few uses for this service but I
will let my co-authors comment on this.. 

I like a buffer constrained model myself...

>    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).

I will let Phil respond to this... he may have some other ideas.

I will be writting a service here shortly on buffer contrained
use of PR-SCTP... more targeted for ipfix...

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

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 31 May 2002 18:11:14 -0500

> a message). Either case, there will be problem.
                                   ^^^^^^^^^^^^^
                              ...will be *no* problem...