Subject: [Tsvwg] SCTP_SEND_FAILED structure problems

From: Mark Butler <[email-masked]>
Date: Fri, 03 Mar 2006 01:07:24 -0700

Hello everyone,

Another problem - the structure of the SCTP_SEND_FAILED notification is 
broken because sctp_sndrcvinfo is embedded into it and further, because 
ssf_data[] is at a fixed offset from the beginning, making extensions to 
either structure difficult.

It could be fixed by adopting the convention that ssf_length does not 
include the length of the attached data or the sndrcvinfo structure,  
and instead placing the sndrcvinfo and the message data in independent 
structures with standard (type/flags/length) prefixes, all as part of 
the same notification terminated with MSG_EOR.  The data part should 
support more than one data fragment with offsets and transmit/ack status 
for each.  Something like:

struct sctp_send_failed {
    uint16_t ssf_type;
    uint16_t ssf_flags;
    uint32_t ssf_length;
    uint32_t ssf_error;
    uint64_t ssf_complete; 
    sctp_assoc_t ssf_assoc_id;
};

struct sctp_send_failed_info {
    uint16_t sfi_type;
    uint16_t sfi_flags;
    uint32_t sfi_length;
    struct sctp_sndrcvinfo sfi_info;
};

struct sctp_send_failed_data {
    uint16_t sfd_type;
    uint16_t sfd_flags;
    uint32_t sfd_length;
    uint64_t sfd_offset;
    uint32_t sfd_data[0];
};

ssf_complete would be the cumulative acked data offset starting from the 
beginning of the message, giving a reasonable indication that the peer 
application probably has the data to that point.

There should be an option to specify how many bytes from the beginning 
of the message should be saved for identification / retransmission / 
logging purposes.

Comments?  Has the current structure been set in ABI stone anywhere yet?

 - Mark

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