>>>>> On Fri, 30 Nov 2001 10:56:21 -0800 (PST),
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
> No kidding. I have pretty strong feelings that the changes related to
> section 4.1 are bad. Primarily because this behavior was specified more
> that two years ago. It has been implemented by multiple vendors. The
> previous definition of how ancillary data was to be received by TCP
> applications was workable as written, given some clarifications. A
> Wholesale discarding of the mechanism was unnecessary.
> I regret that I missed the discussion which resulted in the "consensus" to
> change this. It should be changed back to its previous behavior.
Please note that I didn't say this change was based on a "consensus."
As one of the "vendors" that implemented the old behavior, I'm even
happy with a less radical change as long as the spec provides an
application not receiving data segments with the ability to get
the optional information.
An alternative candidate is to allow the stack to pass ancillary data
items even without TCP data (recvmsg() would then return 0 in such a
case.) With this approach, however, the application may not be able
to determine the termination of a connection. The traditional coding
style like
if ((n = recvmsg(s, &msghdr, 0)) == 0)
return(-1); /* end of the connection */
does not work, because this can be an ack-only segment with ancillary
data. Instead, the application would have to do the following test:
if ((n = recvmsg(s, &msghdr, 0)) == 0 && msghdr.msg_controllen == 0)
return(-1); /* end of the connection */
I can personally live with this change of style. I'd like to hear
from other implementors.
BTW, if we go back to the recvmsg() + ancillary data approach, I think
we should reconsider the following part of rfc2292bis-02
For efficiency reasons it is recommended that a
TCP implementation not send ancillary data items with every received
segment but instead try to detect the points in the data stream when
the requested IPv6 and extension header content changes and only send
a single ancillary data item at the time of the change.
(Section 4.1, second paragraph)
This is because we do not assume any ordering and number of
occurrences about extension headers in the incoming segment and thus
it is not feasible to detect changes over different segments. So, I'd
like to remove this recommendation. In any event, the ancillary data
cannot fully follow the changes and the application cannot rely on the
mechanism. Thus, IMO, if the application cares about the efficiency,
it should simply disable receiving the optional information.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
