Subject: Re: TCP implication of 2292bis

From: Tim Hartrick <[email-masked]>
Date: Mon, 17 Dec 2001 13:22:36 -0800 (PST)

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

This is almost certainly true.
 
> 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.
> 

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.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 18 Dec 2001 06:23:59 +0900

>behavior is simpler is any respect.

	the major problem I'm seeing for -02 definition is that there's no
	relationship defined (impossible) between the normal TCP data stream
	and ancillary data segments.  I personally in favor of -03 definition.

itojun

---

From: Atsushi Onoe <[email-masked]>
Date: Tue, 18 Dec 2001 09:32:55 +0900 (JST)

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

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.

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.

Atsushi Onoe