Subject: [Tsvwg] Re: [Fwd: PRSTCP-00]

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Jun 2002 16:43:17 -0500

Randall,

Please see comments below...

On Thu, 06 Jun 2002, Randall Stewart wrote:

> "Brian F. G. Bidulock" wrote:
> > 
> > Randall,
> > 
> > Two comments and a question:
> > 
> > 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... 
> 
> > 
> > 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.
> 
> 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...

What if the SSNs in these TSNs are reliable?  They have been
dropped and yet they have not been successfully delivered to
the peer.  This compromises the reliability of all other "reliable"
messages.

--brian

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

-- 
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: Randall Stewart <[email-masked]>
Date: Thu, 06 Jun 2002 18:02:56 -0500

> the peer.  This compromises the reliability of all other "reliable"

Brian:

I am a bit confused.. it is probably just late in the day and also
the classes I am in :0

So could you help me with this ... I want to understand (and I am not
:<)

So in my example...

Are you saying something before 101 is NOT to be skipped i.e. reliable?

If so I would not do a fwd-tsn to 101 but to an earlier number....

If you could illustrate this with the above example it might help
me understand what you mean...

R