Thanks Vlad for the careful reading, and thanks Erik for the quick
response.
>>>>> On Tue, 5 Feb 2002 10:23:24 +0100 (CET),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> Since, in this case, we instantly know that the packet is dropped, wouldn't
>> it be better to specifically notify the application via a returned error
>> code?
> The X/Open (or whoever "owns" the socket standard now adays) socket
> specifications allow for implementations where certain error
> messages, such as EHOSTUNREACH etc, can not be returned as an
> error to a send/sendto/sendmsg.
> Implementations using asynchronous message passing between the socket layer
> and the procol stack depend on this being allowable behavior.
That's exactly the reason why the specification does not define an
error code in this case. If necessary, I'll put some additional note
on this to Section 11.2, but it will still not specify a particular
error code.
>> > When the application is sending packets too big for the path MTU
>> > recvmsg() will return zero (indicating no data) but there will be a
>> > cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
>> > indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long.
>>
>> What happens to any buffered data? If there is buffered data that came
>> before the MTU error, should recvmsg() still return 0 and no data?
> The assumption is that the mtu indication is a separate "event"
> ("record" for those looking a *BSD socket code) thus in this case
> the application would first receive the buffered data and then receive
> the msg with no data and just msg_control.
That's the same as my intention, and our implementation in fact acts
as above (i.e. the app first receives the buffered data). The comment
is reasonable, so I'll clarify this explicitly.
>> Actually, it's worse then that. For non-connected sockets (I am assuming
>> non-connected
>> means no destination address specified), the ancillary data will be given to
>> all of them.
>> This now places a burden on the application to figure out whether they are
>> sending to a
>> given destination or not. We ether need a warning here that the application
>> may
>> receive MTU ancillary data for a destination they do not care about, or we
>> may want to
>> restrict this to connected sockets only (i.e. the ones with destination
>> address set).
> The purpose of the ancillary data item is to allow applications which do
> not connect() their UDP sockets to correctly participate in path MTU
> discovery.
> So I think it makes sense to put in some explicit text saying that the
> application needs to verify that it indeed has sent a packet to the
> desination.
OK.
> However, in practise I don't see this being an issue. A UDP application
> participating in path MTU discovery (i.e. any UDP application which wishes
> to send packet larger than 1280 bytes) must maintain path mtu state for
> all the peers it is sending data to. So receiving the IPV6_PATHMTU,
> just means it need to find that state and update it.
I agree, and, please also note that IPV6_RECVPATHMTU is disabled by
default. Thus, almost all applications would not receive the noisy
ancillary data.
>> Why limit this functionality to only a connected socket? Is it because
>> of the odd semantics with providing data to a getsockopt? I mean, the
>> application
>> could set the ip6m_addr to the destination address it wants to look up the
>> MTU for,
>> but it would be a little strange for an application to specify data on a
>> getsockopt().
> s/a little strange/completely inconsistent with getsockopt as defined/
> One could envision being able to ask questions about destination addresses
> where path MTU is one of the things to ask.
> But this quickly evolves into being able to ask about other useful things
> (cached rtt estimate, etc). I belive RTM_GET with routing sockets already
> provides an API for asking all those questions.
> Would it be useful to add a pointer to routing sockets in the spec?
Hmm, it's okay with me, but, we may even have to remove the section
and just mention the possibility of the more generic mechanism. Do we
really have to need the specific interface (i.e. IPV6_PATHMTU)?
(If there's no strong opinion, my default take will be to keep the
current spec with some note on the general interface.)
>> Section 14.2 and 14.3 [pages 51 and 52]
>>
>> It may be worth mentioning that AF_UNSPEC may also be used as an argument to
>> rcmd_af and rexec_af for protocol independent applications. This aligns this
>> API closer to the basic api.
> OK
Okay with me, too. Actually, our implementation of rcmd_af() has
already supported the case of AF_UNSPEC.
I'll soon revise the draft with taking all into account. If anyone of
you has further comments, please make them here.
Thanks,
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]
--------------------------------------------------------------------
