Subject: [Tsvwg] SCTP IG (SACKs)

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 1 Jun 2002 15:21:28 -0500

Randall,

draft-ietf-tsvwg-sctpimguide-05.txt Sction 2.7 places a MUST on
sending gap reports.  Before when this was a SHOULD, it was obvious
that gap ack blocks in a SACK which exceeded an MTU could be
truncated.  Now it is not so clear.  What should an implementation
do if the number of gap ack blocks in a SACK exceeds the path MTU?
Truncate?  Force IP fragmentation?

--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: Mon, 3 Jun 2002 16:40:27 -0400 (EDT)

> draft-ietf-tsvwg-sctpimguide-05.txt Sction 2.7 places a MUST on
                                      ^^^^^^^^^^
you mean section 2.8

> Truncate?  Force IP fragmentation?

I think what is desired is that SACKs SHOULD send gap reports, where the
only reason for not sending a gap report is due to truncation. So what
about the following wording...

"Any received DATA chunks with TSN greater than the value in the
Cumulative TSN Ack field are reported in the Gap Ack Block fields. The
SCTP endpoint MUST report as many Gap Ack Blocks that can fit in a single
SACK chunk limited by the current path MTU."

~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: Mon, 3 Jun 2002 15:57:42 -0500

Armando,

> > draft-ietf-tsvwg-sctpimguide-05.txt Sction 2.7 places a MUST on

That would be fine with me.  I just want to truncate on path MTU
(which is quite a few gap reports and or dups).  Perhaps it should
be mentioned that duplicate TSN reports should be truncated in
preference of reporting GAPs.

--brian

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 03 Jun 2002 20:28:50 -0500

...
> Perhaps it should

I think this is a good point.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Mon, 03 Jun 2002 18:36:29 -0500

Armando/Brian:

Being bored by a process lecture.. I have a few moments :>

I see no reason to make this change... because .. as I said Lixia
already provided for this...

Page 82 of RFC2960 right before 6.8:

" 
   The maximum number of Gap Ack Blocks that can be reported within a
   single SACK chunk is limited by the current path MTU.  When a single
   SACK can not cover all the Gap Ack Blocks needed to be reported due
   to the MTU limitation, the endpoint MUST send only one SACK,
   reporting the Gap Ack Blocks from the lowest to highest TSNs, within
   the size limit set by the MTU, and leave the remaining highest TSN
   numbers unacknowledged.

"

the MUST in the impl-guide just makes it so you MUST send Gap ack
blocks.
The above wording still applies and is NOT effected by this change..

We may want to add a bit to the above to state that duplicates are
dropped first before gap ack blocks... that is not specified but
I think it is implied already...

R

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 03 Jun 2002 12:25:47 -0500

Brian:

Don't have time to check now but I think this case is
already covered... it tells you to truncate the highest
gaps off...

I think Lixia wrote on this issue in the original RFC...

I am in a class and have been away from email for quite a bit
so I am backlogged.... I will have a look when things calm down
for me a bit :>

R