Subject: [Tsvwg] More on PRSCTP-00

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 May 2002 11:39:15 -0500

Randall,

More problem with PRSCTP:

Because FORWARD TSN is done on a TSN basis only, it reintroduces
Head-Of-Line blocking: if the SSNs following a drop arrive at the
receive out of order on an ordered stream, it is not possible for
the receive to determine what is the next expected SSN in the
stream because the FORWARD TSN contains no information about which
SSNs were dropped.  Therefore, after a drop reported in an FORWARD
TSN, every stream is blocked from delivering to the ULP until all
missing TSNs have arrived.  This is HOL blocking again.  I would
think that the FORWARD TSN procedure should reduce delay in delivery
to the ULP rather than increase it.

One solution to this is to report dropped SSNs.

--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:41:59 -0400 (EDT)

> to the ULP rather than increase it.

Yeah, I discussed this issue with Randall and Qiaobing last July. To solve
the issue, we considered sending the equivalent of a cum ack but at the
stream level. So the forward tsn would report the last SSN for each stream
which has been cum acked. The problem is that the forward tsn chunk could
potentially get very large. So we never solved this problem...

> One solution to this is to report dropped SSNs.

Sounds similar/same as our failed solution, right? If not, please
elaborate a little. It would be nice to fix this problem.

~armando

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

---

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

> to the ULP rather than increase it.

But one must make a distinction between this case and the original HOL
issue SCTP is meant to address: this is one SSN delaying another SSN in
the *same* stream, while the original HOL is one message in a stream
delaying messages in other *different* streams. These two cases are very
different. So, to day HOL is back is simply not true.

We all understand and agree that the original inter-stream HOL is bad to
multiple session based traffic. However, the consequence of this
intra-stream delay (I don't even know I should call it HOL) is very
unclear. We had this discussion earlier (as Armando mentioned). One view
to look at this is, when the sender chooses to use "timed reliability"
messaging over the stream, it should be prepared to accept this possible
intra-stream delay on some of the message deliveries.

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 31 May 2002 19:03:49 -0500

> elaborate a little. It would be nice to fix this problem.

After a little more thinking, I am no longer even sure that I know what
the delay is :-)

Say, you send msg1 and msg2, and msg1 has a limited lifetime and msg2 is
forever valid. And you transmit them out at about the same time, but
msg1 is lost. 

For the sake of this discussion, assuming the one-way path delay is
200ms.

Without PR-SCTP, 
  at t=0:       the receiver gets msg2 and sends a gap SACK back.
  at t=200ms:   the sender marks msg1 as missing (strike 1)
   ....
  at t=x:       the sender finally retransmits msg1
  at t=x+200ms: msg1 arrives and the receiver delivers both to ULP.

The delivery delay on msg2 is x+200ms.

With PR-SCTP,
  at t=0:       the receiver gets msg2 and sends a gap SACK back.
  at t=200ms:   the sender marks msg1 as missing (strike 1)
   .....
  at t=y ( <x)  msg1 expires.
   ....
  at t=x:       the sender finally decides to retransmit msg1 but
                finds it's too late. So it drops it and sends a
                Fwd-TSN
  at t=x+200ms: Fwd-TSN arrives and the receiver delivers msg2.

The delivery delay on msg2 is x+200ms.

Why do you say PR-SCTP introduces more delays to the message delivery?
Maybe You are thinking if there is some magic way that the receiver can
be told at t=y to release msg2 from its re-ordering queue.... I would
like to know that magic solution.

-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 May 2002 19:53:33 -0500

Qiaobing,

Well, that's not really what I was gettin at: consider just the
receiver's view of this sequence:

<-- TSH   SID  SSN

    101    1    2
    102    1    3
    103    2   57
    104    2   58

    FORWARD TSN 106

    108    1    5
    109    1    6
    110    2   60
    111    2   61

Now, because the receiver cannot tell whether SID/SSN (1/4) was
dropped or whether SID/SSN (2/60) was dropped (until it receives the
missing TSN 107), missing TSN 107 has blocked both streams.  If more
streams were involved in the same way, they would all be blocked by
the loss of one TSN.  This *is* inter-stream HOL blocking.

The problem is not as great as I first thought (all streams
blocked), really it is just streams that have dropping that are
blocked, but the problem is still of concern: particularly as it is
congestion which causes drops in PR-SCTP in the first place, one can
expect packet losses at about the same time.

The delay introducted is blocking (in the example), delivery on
stream 1 and stream 2 until TSN 107 can be finally and successfully
delivered.

If FORWARD TSN included the fact that, say, stream 1 should "expect"
SSN 5 and stream 2 should "expect" SSN 60 (because 4 and 59 have
been dropped), then there would be no blocking.

In general I don't see a problem with putting the SID/SSN in the
FORWARD TSN.  Certainly the sizeof of the FOWARD TSN chunk could be
limited in similar ways to SACK chunks (advisory only), then the
approach appears to be a sound one.

--brian