Subject: Re: TCP implication of 2292bis

From: Tim Hartrick <[email-masked]>
Date: Tue, 18 Dec 2001 10:20:40 -0800 (PST)

Vlad,

> 
> > 
> >   And, of course, either approach has impact on existing
> >   implementations, and the impact depends on the spec that the
> >   implementations are using.  As I said in the presentation, the 02
> >   approach affects RFC2292-based implementations much, and the 03
> >   approach affects 02 (or earlier) based implementations much.  So I'd
> >   like to hear from other implementors.
> > 
> >   Again, though I prefer the 03 behavior, I know (and understand) some
> >   other people dislike it.  I'll hear from others, and will obey the
> >   consensus. 
> 
> If we can not reach consensus (don't gasp, it happened before), may I suggest
> that we document both behaviors.  We can keep a strict 2292bis-02 behavior
> (i.e
> don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior
> with
> the limitations in section 4.1 (i.e applies only to TCP and can only be used
> with
> getsockopt).
> 
> Both calls will return identical information and MUST be used exlucsively of
> each other (i.e use one or the other, not both).
>

With regard to how the -02 behavior works, it isn't at all clear to me that
the -02 behavior can't be made to return extension headers that arrive on
non-data bearing segments.  That is an implementation detail.  It may be that
returning such extensions is more difficult for some implementations than
others.  It hasn't proven to be a showstopper for us.  The negotiation of
of certain extensions is another matter.

I appreciate the desire to satisfy both sides but the above suggestion merely
guarantees that the implementation is more than twice as complicated as it
would be if we only selected one mechanism.

Given the dubious utility of this facility I far prefer no mechanism to two
mechanisms.  The fact that the mechanisms are removed from this document does
not preclude implementations from making them available.

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: Vladislav Yasevich <[email-masked]>
Date: Wed, 19 Dec 2001 13:31:28 -0500

I've been thinking about the suggestiong of removing
the tcp handling from the document and keep comming up
with the following 2 questions:

1.  Why was the change made origianlly in the 2292bis?

and

2.  Why change now back to the original 2292 definition?

I don't know the answere to 1 (may be Eric can help?) and
noone has sufficiently answered 2.

Thanks
-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 20 Dec 2001 14:34:24 +0900

>>>>> On Wed, 19 Dec 2001 13:31:28 -0500, 
>>>>> Vladislav Yasevich <[email-masked]> said:

> noone has sufficiently answered 2.

Okay, they are reasonable questions.

I searched in the web for old discussions and I think I found the
answer to the question 1.  (You can check the discussion at the
following URL
http://www.wcug.wwu.edu/lists/ipng/199803/threads.html
with the subject "Advanced Sockets API Issue")

The very first motivation was that (old) IPV6_PKTOPTIONS was not
symmetric, that is, it was used to specify sticky options for outgoing
packets with setsockopt(), while it was used to retrieve received
optional information with getsockopt().  The proposed solution was to
change the semantics of getsockopt() side so that it would just return
the content specified by setsockopt().  With this change, we'd need a
separate mechanism to provide the ability to retrieve received
optional information.  Using recvmsg() (for TCP sockets as well) was
proposed for this purpose.

Another reason was to provide a single, uniform interface to retrieve
the received optional info, i.e., recvmsg() + ancillary data.

There was also discussion on if we should provide the ability to trace
changes on the optional information for TCP sockets and if the kernel
should check the changes to omit passing ancillary data for efficiency
reasons.  I didn't see consensus on this discussion in the list
archive.

And, the reason for the change in rfc2292bis-03 is as follows (I know
the reasons are controversial and someone have an objection):

1. despite the change, the rfc2292bis-02 behavior did not provide
   a TCP socket with the complete ability that is available for UDP and
   raw-IPv6 sockets.  For example, it did not provide the ability to
   trace the changes.  Thus, there was less advantage to introduce the
   change.

2. the rfc2292bis-02 behavior did not provide a send-only TCP
   application with the ability to retrieve optional receive info,
   while RFC2292 provided the ability.  In other words, rfc2292bis-02
   was not upper-compatible to RFC2292 in terms of its function.

3. there are currently RFC2292-style applications deployed.  It is easy
   for such applications to migrate to rfc2292bis-03 than to
   rfc2292bis-02.  (The opposite argument may apply for
   rfc2292bis-02-style applications, of course.)

Finally, the following is my personal opinion (and preference) based
on all of above.

As for the symmetric behavior in the original motivation, we've
already solved it by separating IPV6_XXX and IPV6_RECVXXX.  So, there
is no reason to use recvmsg() + ancillary data on TCP sockets for this
reason.

As for the motivation of a single and uniform interface, I see some
benefit.  However, I'm not sure if this really helps application
programmers.  Due to differences between TCP and UDP/raw-IPv6 (more
accurately, differences between STREAM and DGRAM) we cannot provide
both type of sockets with exact the same behavior.  Also, most
application programmers are not familiar with using recvmsg() for TCP
sockets, as far as I know.  Even with the fact this is an "advanced"
API, I'd rather separate the retrieving mechanism for TCP and others
with clearly stating that the getsockopt() approach can only be used
for TCP sockets.

In summary, I'd still support the 03 behavior if we had to choose one.
However, since the usage of receiving the optional info on TCP sockets
is relatively a minor issue, I'm okay with leaving it unspecified if
we cannot reach consensus.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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, 21 Dec 2001 01:23:45 +0100 (CET)

> with the subject "Advanced Sockets API Issue")

Thanks for digging up the history - I couldn't recall all the details.

>    rfc2292bis-02-style applications, of course.)

Are there TCP applications which use RFC 2292 style for accessing received
extension headers?
I thought we had concluded that no TCP applications existed that access
the received stuff (even tough telnet can set things like routing headers
for transmit).

> is no reason to use recvmsg() + ancillary data on TCP sockets for this

Yes, but the semantics of IPV6_RECV* on UDP and raw is to enable receipt
which is quite different that actually receiving the content.
Thus they are boolean (int32_t) socket options.

*If* there is a need to have socket options to extract the received
extension headers from the kernel I think it would make sense to
use different socket options and not overloading the existing ones.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 21 Dec 2001 18:38:44 +0900

>>>>> On Fri, 21 Dec 2001 01:23:45 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> the received stuff (even tough telnet can set things like routing headers

Okay, compatibility to existing applications should actually not
matter.

> use different socket options and not overloading the existing ones.

I'm not sure I can get this argument...in the 03 behavior (as well as
in 02), the IPV6_RECVXXX options always set/get an integer, regardless
of the socket type (TCP/UDP/raw).  These options just tell the kernel
if the application wants to receive the incoming extension headers (or
other optional info).  Then, in 03, UDP or raw sockets get the
information as ancillary data and TCP sockets get it via a separate
socket option "IPV6_PKTOPTIONS."  I think there is no overloading
here.

Anyway, I think I provided all information to make a decision.  If we
can reach consensus on a single behavior through all the information,
I'll put it in the next revision of the draft.  Otherwise, I'll just
leave this part unspecified (perhaps with some background.)

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Dec 2001 18:25:07 +0100 (CET)

> Okay, compatibility to existing applications should actually not

I had a more fundamental question: does there exist even one TCP application
which receives extension headers?
I haven't seen one.

You seemed to say that such exist. If they do it would be useful to
look at those TCP applications to see what they are trying to do
and which flavor of the API fits better.
And if they exist it might not make sense to remove everything about
TCP applications receiving extension headers from the spec.

> socket option "IPV6_PKTOPTIONS."  I think there is no overloading

You're right. I seemed to have read that a getsockopt of IPV6_RECV* would
return the information.
Using IPV6_PKTOPTIONS does not have overloading problems.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 22 Dec 2001 02:50:57 +0900

>>>>> On Fri, 21 Dec 2001 18:25:07 +0100 (CET), 

> which receives extension headers?

I still seemed to be unclear...No, I've never seen one, either.

(There was actually one (and only one) TCP application that tried to
get receiving interface at the accept() time.  It was a BGP4+ daemon,
which needed the interface to disambiguate link-local peers.  However,
we now have the sin6_scope_id field in sockaddr_in6{} and do not need
the information for this purpose.)

> TCP applications receiving extension headers from the spec.

Agreed.  But (again) I've never seen such applications with the
exception above, which does actually not need the receive info using
the current basic API.  I can't imagine such applications in a
foreseeable future either.

					JINMEI, Tatuya