Subject: [Tsvwg] SCTP: GAP ACK without a gap

From: Tom George <[email-masked]>
Date: Sat, 03 Nov 2001 17:28:38 -0600

On the SIGTRAN list there has been some discussion of a problem that
M2PA has in using SCTP. SCTP acknowledges incoming messages independent
of delivery to the upper layer. This can result in message loss in
certain cases. 

There needs to be a way for the M2PA to withhold acknowledgement of a
message until it can be determined that the message can be processed.
One of these ways involves an unintended method of using GAP ACKs
described below.  

I think this is the method we want to recommend in M2PA. The alternative
would probably be the very drastic step of adding sequence numbers and
queues to M2PA. This seems like a lot of work (and duplication of SCTP
capability) just to be able to withhold an acknowledgement. 

But I would like to know if there are any problems with using this
method. 

Randall thought that some SCTP implementations might abort the
association when receiving this kind of GAP ACK. I don't think that is a
problem for M2PA. We just want SCTP to have the option of not aborting. 

Following are the messages on the SIGTRAN list that discussed this. The
thread was "M2PA: Acknowledgement Problem".

tomG.

=====================================================

On Fri, 25 May 2001 Brian F. G. Bidulock wrote: 
> Tom,
> 
> Actually, there is a sneaky way of getting SCTP to deal with
> this if one has control of the SCTP implementation.  That is
> to GAP ACK TSNs which have not yet been accepted by the ULP.
> Something like this:
> 
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 48
> 
> to acknowledge receipt of TSN 48 so that it gets struck from
> bytes in flight but is held by the transmitter in case we
> reneg or the association aborts.
> 
> The next ones might look like:
>         
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 48
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 50
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 52
> 
> then, when 48 through 51 have been accepted by ULP:
> 
>         SACK:    Cummulative TSN = 51, GAP ACK = 52 to 52
>         SACK:    Cummulative TSN = 51, GAP ACK = 52 to 54
> 
> If this can be done, then all that M2PA would have to do
> before sending status Busy or Processor outage is stop
> servicing SCTP's read queue for streams 1 through N.  M2PA
> would simply use the TSN of the last received MSU (truncated)
> in the changeover message.
> 
> This would not impede SCTP's RTT calculations or be as
> drastic as artificially dropping rwnd to 0.  I don't know
> how an existing implementation will take to having a GAP ACK
> thrown at it that doesn't have any real gaps.
> 
> --Brian

=====================================================

On Fri, 25 May 2001 Randall R. Stewart wrote:
> Brian
> 
> Actually it probably would work fine with
> most implementations...not that I would recomend this...
> 
> But when you think about the way you implement this
> you normally go through and process the CUM-TSN first.
> Remove up to the CUM-ACK then you process the GAP's 
> seperately... Now some implementations may attempt 
> to collapse any consecutive TSN's but this is 
> really not right... One of the implementations at
> the last bakeoff (if I remember right) was real good
> at detecting things like this... however their solution,
> (if a peer was doing something like this) that was not
> to their liking was to abort the assoc.
> 
> So probably it would work or abort the association :0
> 
> R

=====================================================

-- 
* Tom George        972-519-3168         [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 05 Nov 2001 06:10:05 -0600

Tom:

Has I said before.. this will work. Thinking of the kernel
work we have just about completed for BSD it would
do exactly what you want... 

One side effect of this of course would be you would
NOT be raising the cwnd. Since you cannot advance your
cwnd UNLESS the cum-ack point advances.

This is probably not an issue for the sigtran adaption layer
but it is something to consider.

Also one MAY have a implementation that detects this and
aborts (as I said earlier). Not that any implementation I
have ever done would do so....

R

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

---

From: David Lehmann <[email-masked]>
Date: Mon, 05 Nov 2001 08:18:30 -0500

> > really not right... One of the implementations at

I thought collapsing was right.  I think there was a discussion
on this subject back in 9/2000 in the thread,
"Order of Gap Acks SACKs".  However, the sigtran
archives files for the year 2000 have zero lengths. 
So I can't be sure. :-(   Does anyone recall or have
access to the archive?

-David

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 05 Nov 2001 16:31:16 -0600

Tom,

This sounds to me an exploitation of SCTP by turning SCTP gap acks into
a way of buffer management. To me, the whole idea here is to try to
trick the SCTP data sender to perform temp data buffering while the M2PA
layer at the SCTP receiver does not need to worry about data buffering.
I don't think this is right.

The right way is to only read the next message from SCTP layer when the
M2PA layer is sure that it is going to process the message. If it wants
to look ahead a few message before it can determine whether to process
the current message, then the M2PA should read-out and buffer these
message in its own buffer.

Technically, I don't recall anywhere in RFC2960 saying that: 
     SACK:    Cumulative TSN = 47, GAP ACK = 48 to 48

is NOT semantically identical to:
     SACK:    Cumulative TSN = 48.

Therefore, to require the data sender to treat the above two versions
differently requires protocol change, which I don't think should happen.

-Qiaobing

---

From: Chip Sharp <[email-masked]>
Date: Tue, 06 Nov 2001 00:13:59 -0500

>I don't think this is right.

Unfortunately, this is an undesirable effect of adding the ability to renege.
I'd be happy to get rid of it. :-)

>      SACK:    Cumulative TSN = 48.

The spec differentiates between a TSN being in the Cum TSN Ack and a TSN 
being in a Gap Ack (e.g., in increasing cwnd, ability to renege).

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 06 Nov 2001 10:47:46 -0600

Hi, Chip,

My comments in-line...

> I'd be happy to get rid of it. :-)

The renege procedure itself is nothing wrong and is important to keep
since otherwise there will be a deadlock. The problem is that people may
abuse it. I think we've anticipated this "undesirable effect" and put
the following strong word in the RFC to warn people about reneging data.

"
   An endpoint SHOULD NOT revoke a SACK and discard data. Only in
   extreme circumstance should an endpoint use this procedure (such as
   out of buffer space).  
"

What M2PA people is trying to do with renege is exactly what the RFC
tells people not to do. To me this is clearly a case of abuse.

-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 12:01:41 -0600

Qiaobing,

> tells people not to do. To me this is clearly a case of abuse.

What reneg?  We never asked for a reneg.

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 06 Nov 2001 12:13:37 -0600

> What reneg?  We never asked for a reneg.

Was that the motivation behind faking a gap segment when there is no
gap, so that the TSNs in the faked gap segment can be reneged later?

-Qiaobing

---

From: Tom George <[email-masked]>
Date: Tue, 06 Nov 2001 15:20:03 -0600

On Tue, 06 Nov 2001 12:13:37 -0600, Qiaobing Xie wrote:
  [...]
> gap, so that the TSNs in the faked gap segment can be reneged later?
  [...]

The purpose of faking the gap segment was to make the sender keep the
message in his send queue until the receiver knows it can be processed.
That way, if there is a failure in an upper layer at the receiver, the
upper layer at the sending end can retrieve the message from its SCTP
and send it over another SS7 link.