Subject: Re: TCP implication of 2292bis

From: Tim Hartrick <[email-masked]>
Date: Mon, 17 Dec 2001 16:58:33 -0800 (PST)

> 
> > Simplest is in the eye of the beholder.  We have implemented the -02
> > behavior and the -03 behavior in the past.  I would not agree that the -03
> > behavior is simpler is any respect.
> 
> So we all have implemented the -03 behavior.  Why changes are needed?
> The -03 behavior, which is almost same as existing RFC 2292 behavior,
> works fine even for receive only applications or with shutdown.
>

Yes, we implemented something like the -03 behavior four years ago.  There
is little reason to resurrect it since the -02 behavior was specified almost
three years ago, has been implemented and works.

I don't know who "we all" is here.  I don't believe Vlad's team has implemented
the -03 behavior and while we have implemented it in the past we don't really
care to bring it back.  The -02 behavior has been specified for almost three
years.  It has been implemented and shipped.  There seems to be no clear
consensus for a change (3 for, 2 against).

> I believe that the reason for recvmsg() raised in 2292bis was to trace
> the changes in extension headers and other parameters for receiving
> applications.  But it is obviously impossible for TCP.
>

Impossible seems to be a strong word.  I don't agree.

> So the only reason to keep -02 behavior would be similarity for UDP.
> Most of TCP applications is not so similar to UDP and required changes
> for existing TCP applications is minimum in -03, IMO.
> 

Since there doesn't seem to be consensus for the change made between -02
and -03 the -02 behavior should hold.  If not then both mechanisms should
be excised from the document.  We have wasted enough time on a facility of
dubious value.

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: Atsushi Onoe <[email-masked]>
Date: Tue, 18 Dec 2001 10:06:11 +0900 (JST)

> If not then both mechanisms should
> be excised from the document.

Actually, it is acceptable for me.

> We have wasted enough time on a facility of
> dubious value.

Agreed.

Atsushi Onoe

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 18 Dec 2001 10:33:08 +0900

>>>>> On Tue, 18 Dec 2001 10:06:11 +0900 (JST), 
>>>>> Atsushi Onoe <[email-masked]> said:

> Actually, it is acceptable for me.

Okay with me, too.  I just tried to make the document clear in the 03
draft, but in fact I don't see practical usage of receiving the
optional information on TCP sockets.  If we can reach a consensus of
leaving it unspecified (by removing the text), it's just fine.

I'll hear from others for a while, then revise the text along with
this approach if no one makes an objection.

					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: Tue, 18 Dec 2001 07:34:49 +0100 (CET)

> leaving it unspecified (by removing the text), it's just fine.

At one level I don't have a problem with removing the 02 and 03 behavior since
no TCP applications use this.

However, I wonder what we would do if a TCP application comes around and
wants to either restrict the extension headers used on the receive side and/or
be aware of what is used.
Perhaps this is something we can only speculate given that no such
applications exist.

  Erik

---

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

>>>>> On Tue, 18 Dec 2001 07:34:49 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> Perhaps this is something we can only speculate given that no such

As for the restriction, we cannot take the same approach as UDP and
raw IPv6, i.e., making a decision by receiving the extension headers
at the application side.  So, the restriction mechanism should be a
kind of packet filtering at L3 or L4, and applications can only
control the filter policy by some other APIs that are totally
different from the ones we're talking about.

As for the awareness of what extension headers are used, the problem
is that we don't have concrete usage of it.  Additionally, even if we
provided a way, it would not be very useful because we'd not be able
to follow changes on the extension headers (perfectly).  Meanwhile, we
have already had system-dependent interfaces to grab the headers,
e.g. BPF or DLPI.  An application could use such interfaces if it
strongly wanted to get the extension headers (and other optional info)
for some very special purposes, though such interfaces may require
additional privilege.

If we can reach consensus on removing the current (and previous) text
and want to make some comments on this, I'd propose to put
considerations like above into the next revision of the draft.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Dec 2001 15:16:38 +0100

In your previous mail you wrote:

=> I have not yet an opinion (so to leave it unspecified is by default
my option :-).

Regards

[email-masked]