Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 03 Dec 2001 14:24:23 +0900

>>>>> On Fri, 30 Nov 2001 10:56:21 -0800 (PST), 
>>>>> Tim Hartrick <[email-masked]> 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-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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 13 Dec 2001 11:19:40 +0900

>>>>> On Mon, 03 Dec 2001 14:24:23 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> 		return(-1);	/* end of the connection */

I've considered a bit more about this issue.  Here is a comparison
between those two approaches with pros and cons list:

Pros and cons of using the (new) recvmsg() approach:
  pro: easy migration from 2292bis-02 (and before) applications
  pro: less impact on existing 2292bis-02 (and before) kernels

  con: hard migration from RFC 2292 applications
  con: impact on existing RFC 2292 kernels
  con: impact on the traditional socket semantics
       e.g. need additional condition to detect an end of connection (above)
       e.g. it is not clear what if the app calls shutdown(0)
            (i.e. makes the socket unreadable)?  Should the reception
            of ancillary data also be disabled?

Pros and cons of using the RFC2292-style socket option (described in
the 03 draft):
  pro: easy migration from RFC 2292 applications
  pro: less impact on existing RFC 2292 kernels
  pro: less impact on the traditional socket semantics

  con: hard migration from rfc2292bis-02 (and before) applications
  con: impact on existing rfc2292bis-02 (and before) kernels

So, apart from the impact on the socket semantics, this is a migration
(or backward compatibility) issue.  I'd like to know the current
situation about the deployment of rfc2292bis-02 (or before), and
opinions of implementors that have implemented or have a plan to
implement RFC2292 and/or rfc2292bis.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 14 Dec 2001 10:26:15 +0900

>>>>> On Thu, 13 Dec 2001 11:19:40 +0900, 

>> to determine the termination of a connection.  The traditional coding

(snip)

> implement RFC2292 and/or rfc2292bis.

As I said in the today's meeting, please speak up about your opinions,
if you're interested in implementing the API.  I'd like to collect the
opinions, and will soon revise the draft based on consensus.

Thanks,

					JINMEI, Tatuya

p.s. since I skipped some topics in the presentation, I've put the
presentation slides at the following URL.

http://www.kame.net/~jinmei/mgp/ietf52-advapi/

Please refer to the web version of the slides if necessary.

---

From: Vlad Yasevich <[email-masked]>
Date: Sat, 15 Dec 2001 02:40:18 -0500

Jinmei

Since you are soliciting comments from implementors, here are my
opionions about the change ( I was going to wait until I got to work).

I beleave the the 2292bis-02 definition and TCP implications were
fine.  I was curious about the reasons this was put in the draft.

You said at the meeting that you did this for security/access control
reasons.  I don't think that this was necessary.  The send-only sockets
do not really have a recieve side access control since
the are "send only".  Also, for SIN/FIN/RST packets, since there is
no data that comes to the application, the application did not 
really need to know about the socket options supplied. The app can find
that out when it gets the first data packet at does access control
stuff.

Before I say any more, I would really like to know the reason why
you think the change is needed.

-vlad

---

From: JINMEI Tatuya / ｿﾀﾌﾀﾃ｣ｺﾈ<[email-masked]>
Date: Fri, 14 Dec 2001 18:16:07 +0900

>>>>> On Sat, 15 Dec 2001 02:40:18 -0500, 
>>>>> Vlad Yasevich <[email-masked]> said:

> opionions about the change ( I was going to wait until I got to work).

Thanks for the prompt response (and sorry for urging you.  If anyone
of you are going to show an opinion after doing some work or check on
the implementation, I'm of course willing to wait for the answer.)

> that out when it gets the first data packet at does access control

Perhaps I was not very clear at the presentation.  The reason for the
change (in 03) is NOT security.  I intended to say:

  Despite the change with using recvmsg(), the previous (i.e. before
  rfc2292bis-03) spec cannot follow all the changes on received
  segments.  Thus, it cannot be used for security (e.g. access
  control) purposes (we need to follow the changes perfectly if we use
  the mechanism for security.)  Of course, the 03 behavior (like the
  one in RFC 2292) cannot be used for security purposes either.

  With this reality, the received optional information can only be
  used as "informational" in the sense of the word.  This also means
  that it is meaningless to try to receive the optional information
  for as many received segments as possible.

  So, using recvmsg() with ancillary data has less advantage over the
  RFC 2292 behavior, at least IMHO.

  Meanwhile, using recvmsg() causes additional issues, such as impact
  on the socket semantics or the "send-only apps" problem, which did
  not exist in the RFC 2292 behavior.

  As for the ability to receive optional information at a send-only
  application, it might be true that there is less meaningful usage of
  the ability.  But, anyway, RFC 2292 (and 2292bis-03) provides the
  ability, while rfc2292bis-02 (and earlier) does not.

  In summary, the rfc2292bis-02 behavior has disadvantage over the
  RFC2292 behavior without an (less) advantage.

  That's why I, for one, prefer the 03 behavior.  But I admit that the
  advantage (03 over 02) is not so big and one may say that the
  advantage is not worth the change.  (perhaps I should have just put
  the issue in the "open issues" section.  that was my bad.)

  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.

I hope I'm clearer this time.

					JINMEI, Tatuya

---

From: Atsushi Onoe <[email-masked]>
Date: Fri, 14 Dec 2001 02:41:41 -0700 (MST)

> opinions, and will soon revise the draft based on consensus.

I think the current (-03, and RFC 2292) definition is fine.  For 2292
implementors, there is no new benefit introduced by recvmsg() in
previous revision of the draft.  Even use of recvmsg(), an application
cannot follow the changes of extension headers of duplicated segment,
ACK, RST, FIN.

Actually, I believe most of TCP applications will use neither of
recvmsg() or getsockopt() to get extention headers or some other
infomration, because the connection establishment using SYN/ACK is
automatically made regardless application's behavior.

So I prefer simplest definition to implement such feature if it is
included in the specification.  That's why I think current specification
(-03 draft) is better.

Atsushi Onoe

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 19 Dec 2001 11:56:29 +0900

>>>>> On Tue, 18 Dec 2001 10:53:17 -0500, 
>>>>> Vladislav Yasevich <[email-masked]> said:

> I don't understand why you are assigning advantage to the 2292 behavior.
> So far, both methods provide identical functionality as far
> as the headers received by the application.  

> IMO, both versions add additional complexity to the application, but only
> at the request of the application.

Correct, but I did not intend to assign advantage to 2292.  I just
said that 2292bis-02 did not have advantage to 2292 (or 2292bis-03).

> Are you conserned about not being able to access the extension headers
> sent with ACKs, RSTs, etc...?

> Is this really something that would be usefull to an application?

Well, I'm not sure.  But, actually, I'm not even sure if passing the
received extension headers to applications is really useful at all.
So, we're discussing a corner case of not-so-useful feature, and
that's why I'm inclined to leave this topic unspecified.

> I think providing a meaningless ability is pointless and makes for feature
> bloat and complexity.  It is not a good argument to do something.

> I prefer the 02 behavior because it is cleaner conseptually.  Yes it requires
> code changes for the apps wanting to use it, but most applications do not
> need and will not use this feature.

(same argument as above applies here.)

> 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).

This would also be a possible approach, but I agree with Tim here.  If
we describe some behavior anyway, we should take one and only one
mechanism.  Otherwise it just causes additional complexity and less
portability.

But, again, I'd rather leave this spec unspecified, because we're
talking about something that we're not even sure about the usefulness.

					JINMEI, Tatuya

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 18 Dec 2001 10:53:17 -0500

JINMEI

Thanks, this is a lot clearer.  I'll try to address the points
that you've made since I am still not convinced that we gain
anything by changing the behavior.

Both calls will return identical information and MUST be used exlucsively of
each other (i.e use one or the other, not both).

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