Subject: Re: a question about TCP Implications of rfc2292bis

From: Tim Hartrick <[email-masked]>
Date: Fri, 14 Jan 2000 10:49:47 -0800 (PST)

Jinmei,

> 
> I've implemented Section 4.1 of rfc2292bis-01 (TCP Implications) and
> have a question about receiving options.
> 
> The draft has the following text:
> 
>    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.
> (in the second paragraph)
> 
> My question is "if an extension header disappears in receiving packets,
> how can an application know the fact?" For example, suppose that an
> application set the IPV6_RECVRTHDR option and the peer of the
> application starts sending packet with a routing header. Then the
> application will see the routing header as ancillary data when
> receiving the 1st packet with the routing header. If the kernel follows
> the above text, the application won't see any routing headers unless
> the content of the routing header changes. It seems OK, but what if
> the peer stops sending a routing header? What should the kernel do in
> such a case? Should it send an ancillary data object with the data
> length being zero?
> 
> Note that such a case is not problematic for UDP or raw socket
> applications, since they can detect the lack of routing header by the
> fact that no IPV6_RTHDR ancillary data object is contained in the
> received cmsg list.
> 
> I'm not sure if this has already discussed in the list, but I'd
> appreciate any clarification. Thanks,
> 

These types of situations are the reason I am not enamored of the text
you reference from the draft.  In general I would prefer that we simply
say that all ancillary data will be passed out to user space and leave
it to the application to deal with noting changes, omissions and additions.

The complexity involved is saving all the extensions from each datagram
in the kernel and then comparing them to detect changes doesn't seem
worth it to me.

Depending on how the ancillary data is mananged at the user/kernel boundary
I don't see that there would be that much difference in the efficiency between
the two approaches but simply passing the entire mess out the the application
is simpler on the kernel and guarantees more uniform behavior on which the
application can depend.

The way the text reads today the application can't really depend on the
kernel removing duplicates so the application will need to watch for them
anyway.  Thus, for a portable application you end up with code in user space
and in the kernel doing exactly the same work.

In this case I would vote for the "keep it simple stupid" approach.

tim
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Jan 2000 19:42:35 -0800 (PST)

> it to the application to deal with noting changes, omissions and additions.

I think the text in the draft allows such behavior.
But if the TCP receives N segments with extension headers it can't "compress"
them together when passing them up unless it knows that the extension headers
are the same. Thus if you want reasonable performance you have to
compare extension headers in TCP in any case.
Also, if the messages with ancillary data appear in the socket receive buffer
(or stream head read queue) they can't get received with a single recvmsg
since the ancillary data items might be different.

> I don't see that there would be that much difference in the efficiency
> between the two approaches but simply passing the entire mess out the the
> application is simpler on the kernel and guarantees more uniform behavior on
> which the application can depend.

The issue is how often you have to pass out the mess. If you are forcing
there to be one recvmsg call for every TCP segment performance will suffer
in many cases.

  Erik