headers
Brian F. G. Bidulock | 1 Nov 2003 03:34
Favicon

Re: socket API extension for SCTP checksum

Hanping,

Adler32 is deprecated.

--brian

On Fri, 31 Oct 2003, Hanping Long wrote:

> Hi,
> 
> The SCTP checksum is migrating from Adler32 to CRC32. During the transient
> phase, these two check will be co-existing.
> 
> I am wondering if we could add a preprocessor for the checksum type so that
> the user could choose to inter-op with old SCTP implementation only
> supporting Adaler32 if necessary.
> 
> thanks,
> hanping
> 
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

--

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock <at> openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall R. Stewart (home | 1 Nov 2003 13:22
Picon
Picon

Re: one-to-many/one-to-one socket API extension for SCTP

Hanping Long wrote:

>Hi,
>
>Regarding the one-to-many(UDP style) and one-to-one(tcp style) socket
>interface in socket API, one-to-many is more effiencient in terms of
>exploring the new features of SCTP, can anyone tell me which feature that
>one-to-one style interface CANNOT make use of?
>
>  
>
The big issue (at least I know in KAME-BSD) is that a one-to-one style
socket is not allowed to send data until the connect() or accept() as
completed. This translates into not being able to piggyback data on
the third or fourth leg of the 4-way handshake. The one-to-many uses
implicit connection setup so that when you do a send(data, new-addr); it
will start the connection setup and piggyback the data with the cookie-echo.

At one time there were other features that could not be used by the 
one-to-one style. But
I think for the most mart Kacheong as done a good job of finding ways to 
make them
all work ;->

>Though each association could have its dedicated buffer space for
>one-to-many style API, all the associations will fail if their related
>socket fails. But if one socket fails for one-to-one style API, only one
>association will fail. Is this the benefit of one-to-one style API? or it's
>not possible in reality?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sridhar Samudrala | 1 Nov 2003 16:02
Picon
Favicon

Re: one-to-many/one-to-one socket API extension for SCTP

On Sat, 1 Nov 2003, Randall R. Stewart (home) wrote:

> Hanping Long wrote:
> 
> >Hi,
> >
> >Regarding the one-to-many(UDP style) and one-to-one(tcp style) socket
> >interface in socket API, one-to-many is more effiencient in terms of
> >exploring the new features of SCTP, can anyone tell me which feature that
> >one-to-one style interface CANNOT make use of?
> >
> >  
> >
> The big issue (at least I know in KAME-BSD) is that a one-to-one style
> socket is not allowed to send data until the connect() or accept() as
> completed. This translates into not being able to piggyback data on
> the third or fourth leg of the 4-way handshake. The one-to-many uses
> implicit connection setup so that when you do a send(data, new-addr); it
> will start the connection setup and piggyback the data with the cookie-echo.

In LKSCTP it is possible to do auto connect using sendto()/sendmsg() which
allows bundling of data with cookie-echo. 

> 
> At one time there were other features that could not be used by the 
> one-to-one style. But
> I think for the most mart Kacheong as done a good job of finding ways to 
> make them
> all work ;->
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 2 Nov 2003 06:16
Favicon

Re: minimum TCP MSS

Van,

536.

--brian

On Fri, 31 Oct 2003, Van Dang wrote:

> Does any one know the minimum MSS that TCP must support.
> I think most TCP implementation, without Path MTU Discovery,
> would use the outgoing interface MTU to calculate the MSS
> if the destination is local.  If destination is remote, then use the
> default MSS.  However, some host may try a smaller MSS even
> if locally connected.  So I was wondering what does TCP must
> support in order to be compliant with RFC.
> 
> It would be great if someone knows this answer.  It would save
> me some time from scanning through the RFCs.
> 
> Thanks.
> 
> _________________________________________________________________
> Never get a busy signal because you are always connected  with high-speed 
> Internet access. Click here to comparison-shop providers.  
> https://broadband.msn.com
> 
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
(Continue reading)

Permalink | Reply | 3 comments |
headers
The IESG | 3 Nov 2003 22:20
Picon
Favicon

Document Action: 'Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions' to Experimental RFC

The IESG has approved following document:

- 'Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions '
   <draft-ietf-tsvwg-dsack-use-02.txt> as an Experimental RFC

This document is the product of the Transport Area Working Group Working 
Group. 

The IESG contact persons are Jon Peterson and Allison Mankin.

Technical Summary

TCP and SCTP provide notification of duplicate segment receipt through 
DSACK and Duplicate TSN notification, respectively. This document shows
conservative methods of using this information to identify unnecessary 
retransmissions for various applications. This document does not, however
outline what a TCP or SCTP sender should do after a spurious 
retransmission is detected. It is hoped that future work building on the 
detection of spurious transmissions will make TCP and SCTP more robust
to reordererd packets.

Working Group Summary

The TSVWG supports this protocol going forward, and is investigating 
several proposals that rely on the detection of spurious retransmissions
which might benefit from this work.

Protocol Quality

This document was reviewed for the IESG by Allison Mankin and Jon Peterson.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick Jones | 3 Nov 2003 19:11
Picon
Favicon

Re: minimum TCP MSS

It is my understanding that there is no minimum MSS specified for TCP (well, one
byte is perhaps implicit in TCP being a byte stream rather than a bit
stream...), although some TCP _implementations_ may have settings to reject
connections advertising an MSS less than some value.

Again, unless I am getting beyond my knowledge, 536 is the _default_ MSS - the
MSS that TCP should assume when it does not send or see an MSS option in the SYN
or SYN|ACK segment.

I _suspect_ but cannot quote chapter and verse to confirm, that 536 stems from
the requirement that a conforming IP stack must be able to reassemble IP
datagram fragments into IP datagrams of at least 576 bytes. That is the
"minimum, maximum IP datagram size" an IP stack must support, not a minimum MTU.
(IIRC, the minimum IPv4 MTU is 68 bytes, and 12XX for v6)

If TCP "knows" that the "minimum, maximum IP datagram size" is 576, then it
"knows" that using an MSS of 536 (576 less 20 bytes of TCP header and 20 bytes
of IP header, options may vary :) means that its traffic has at least a
snowball's chance of getting through.

rick jones
--

-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...
Permalink | Reply | 2 comments |
headers
Joe Touch | 4 Nov 2003 00:29
Picon
Favicon

Re: minimum TCP MSS


Rick Jones wrote:

> It is my understanding that there is no minimum MSS specified for TCP (well, one
> byte is perhaps implicit in TCP being a byte stream rather than a bit
> stream...), although some TCP _implementations_ may have settings to reject
> connections advertising an MSS less than some value.
> 
> Again, unless I am getting beyond my knowledge, 536 is the _default_ MSS - the
> MSS that TCP should assume when it does not send or see an MSS option in the SYN
> or SYN|ACK segment.
> 
> I _suspect_ but cannot quote chapter and verse to confirm, that 536 stems from
> the requirement that a conforming IP stack must be able to reassemble IP
> datagram fragments into IP datagrams of at least 576 bytes. That is the
> "minimum, maximum IP datagram size" an IP stack must support, not a minimum MTU.
> (IIRC, the minimum IPv4 MTU is 68 bytes, and 12XX for v6)
> 
> If TCP "knows" that the "minimum, maximum IP datagram size" is 576, then it
> "knows" that using an MSS of 536 (576 less 20 bytes of TCP header and 20 bytes
> of IP header, options may vary :) means that its traffic has at least a
> snowball's chance of getting through.
> 
> rick jones

MSS = Maximum segment size.

TCP's max-min is based on IP's, as noted before.

There is no min segment size - TCP can, and does, send 0-length segments
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Borman | 4 Nov 2003 00:24
Favicon

Re: minimum TCP MSS


On Nov 3, 2003, at 12:11 PM, Rick Jones wrote:

> It is my understanding that there is no minimum MSS specified for TCP 
> (well, one
> byte is perhaps implicit in TCP being a byte stream rather than a bit
> stream...), although some TCP _implementations_ may have settings to 
> reject
> connections advertising an MSS less than some value.

> Again, unless I am getting beyond my knowledge, 536 is the _default_ 
> MSS - the
> MSS that TCP should assume when it does not send or see an MSS option 
> in the SYN
> or SYN|ACK segment.

Yes, see RFC 1122, section 4.2.2.6

>
> I _suspect_ but cannot quote chapter and verse to confirm, that 536 
> stems from
> the requirement that a conforming IP stack must be able to reassemble 
> IP
> datagram fragments into IP datagrams of at least 576 bytes. That is the
> "minimum, maximum IP datagram size" an IP stack must support, not a 
> minimum MTU.
> (IIRC, the minimum IPv4 MTU is 68 bytes, and 12XX for v6)

For IPv4, RFC 791 defines the minimum IP packet size as 68 bytes.  On 
page 25:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geib, Ruediger | 4 Nov 2003 16:08
Favicon

Comments on draft-morita-tsvwg-pps-01

Hello Naotaka,

your revised and new PPS related draft are marked 
as TSV WG, but haven't been announced yet (at least I 
couldn't find an announcement in the archive). After 
reading both, I'm having some remarks, following below.

http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt

Remarks related to morita-tsvwg-pps-01:

While the draft is focused on terminals sending with 
variable rates, the edge traffic control seems to assume 
the peak rate as only parameter characterising the 
controlled traffic. Further, section 8.4 demands 
continuous sending of packets. Does that mean that 
terminals sending with variable rates are expected 
to continuosly create traffic at their peak rate if 
they desire to use PPS?

Your third draft "Measurable Forwarding: A New per-Hop 
Behavior (PHB)" wasn't listed in the "individual 
submissions" section. If IETF didn't accept it this time, 
a url to it would be useful as I think it helps 
understanding pps operation.

The framework could put more emphasis on the "stateless 
core" operation. This feature is a clear and very desirable 
benefit of PPS against other signaling modes. It is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron Falk | 5 Nov 2003 02:41
Picon
Favicon

comments on draft-dawkins-trigtran-linkup-01

Spencer, Carl-

I just read through draft-dawkins-trigtran-linkup-01.txt and have a
couple of comments.  I'm not sure if this document is on the agenda
for tsvwg this IETF so I'm sending my comments now.

Hope this is helpful,

--aaron

--------------

In section 2.3, you say:

   Hosts supporting TCP-based applications over subnetwork interfaces
   subject to multi-second outages MAY perform the actions described
   in Section 3. These actions are more attractive for TCP
   implementations used with "human-in-the-loop" applications, but are
   safe for any TCP-based implementation.

Just to be clear: this proposal is only for end-systems, right?  Not
for routers?  The text here is clearly talking about hosts but later
in section 3 you talk about subnetworks.  The proposal seems a little
vague on this.  I feel like you are saying that he retransmitted
packet may come from a router along the path (as suggested in
draft-ietf-pilc-link-design) but the language seems to imply that it
is _hosts_ saving and retransmitting the packets.  A block diagram
would help. :)

Because, if it is the sender saving and retransmitting the packets and
(Continue reading)

Permalink | Reply | 0 comments |

Gmane