Subject: [Tsvwg] RFC2960bis

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 7 May 2001 16:28:29 -0700

Folks,

Due to the checksum issue, we are planning to reissue RFC2960 with a revised
error check algorithm (the particular check mechanism still to be decided).

We would also like to add in a number of clarifications that have been
identified during the past SCTP bakeoffs, and documented in the draft on
bakeoff results (draft-stewart-ong-sctpbakeoff-sigtran-01.txt):

1) stream negotiation: clarification that the INIT ACK should not specify
more streams than were indicated in the INIT

2) chunk issues: 
  a) propose alignment of chunk parameter type values across all chunk types
(implied in 2960 but not specified)
  b) clarification on how to calculate chunk length (omit any padding at the
end of the chunk)
  c) minor typo in section 3.2

3) heartbeat issues:
  a) count missing HB Acks towards association failure
  b) clarify HB Ack should be a reflection of the received HB, including
any/all parameters
  c) clarify when HB is started and stopped

4) Restart: eliminate DoS case due to restart with new endpoint address

5) Data Transfer: clarify how to grow cwnd

6) Fast Retransmit: clarify use of Gap Acks

These are the main clarifications found in the bakeoffs (the latest bakeoff
did not identify further issues except one regarding IPv6 that will take
more work).

There have been some questions raised regarding heartbeat, but I'm assuming
that these have been resolved.  I would like to see any points raised
against these corrections and clarifications as soon as possible, so that we
can move on with the corrected SCTP spec.  Where there is continuing
disagreement, we'll revert to the original text from RFC2960.

Cheers,

L. Ong

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

---

From: FUKUMOTO Atsushi <[email-masked]>
Date: Tue, 08 May 2001 14:59:07 +0900

One question I have regarding SCTP spec is: Suppose a node A is
configured with two addresses (address A1 and A2), and it received an
INIT chunk in a packet with destination address A1.  When sending
INIT-ACK, MAY I use address A2 as source address of packet, or MUST I
use A1?  There are some discussion in bake-off draft about the choise
of source address, but INIT-ACK seems to be special case since the
initiating node will lack the knowledge of the responding node.

					FUKUMOTO Atsushi
					[email-masked]

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 08 May 2001 07:39:44 -0500

[The host zsc4s004.corpwest.baynetworks.com failed to complete the
mail delivery transaction, so I dropped sigtran from the list of
recipients.]

Another issue that came up at the 3rd bakeoff is DUP reporting.

Should you report a TSN more than once in a given SACK if you get it
more than once?

Nobody thought reporting a TSN more than once was illegal, but most
folks thought a given TSN should only be reported once.  Randy was
adamant that if you are reporting dups at all, you really should
report as many as you can fit into your SACK, including duplicates.

Would somebody who intends to use this data please express an opinion?

> Folks,
> 
> Due to the checksum issue, we are planning to reissue RFC2960 with a
> revised error check algorithm (the particular check mechanism still
> to be decided).
>

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 08 May 2001 07:42:56 -0500

The HOSTNAME parameter in INIT still has not been tested at a
bakeoff.  A few implementations claimed that they could handle it, but
no implementation has come to a bakeoff which has been able to
generate one.

May we drop the feature with the bis?  There are other solutions to
getting SCTP across NAT's.

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 08 May 2001 07:29:06 -0500

Another issue that came up at the 3rd Bakeoff is DUP reporting.

Nobody thought reporting a TSN more than once was illegal, but most
folks thought a given TSN should only be reported once.  Randy was
adamant that if you are reporting dups at all, you really should
report as many as you can fit in your SACK, including duplicates.

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 08 May 2001 09:49:10 -0500

I think the answer really depends on how the DUP reports are used (or
are intended to be use). Sally, any comments on this one?

regards,
-Qiaobing