Subject: Intelligent Multimedia Information Retrieval
From: "Mark T. Maybury" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 23 Dec 1994 18:08:23 -0500

<<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  
<<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  
<<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  

   			   IJCAI-95 Workshop on 
               INTELLIGENT MULTIMEDIA INFORMATION RETRIEVAL

Fourteenth International Joint Conference on Artificial Intelligence (IJCAI-95)
			   Montreal, Canada

          1 day during 19th-21st August 1995 (to be determined) 

BACKGROUND

In the past there has been concerted effort, largely performed in independent
research communities, addressing the automated processing of single media
(e.g., text, imagery, audio).  The advent of large, multimedia digital
libraries has focused attention on the integrated processing and coordination
of multiple media including the traditional focus on textual sources and the
increasing emphasis on media with spatial and temporal properties (e.g.,
sound, maps, graphics, images, video).  While there have been focused
workshops on integration and coordination of multimedia in interfaces and a
national conference on the general subject of multimedia, to date there has
been no targeted forum to address processing issues which cross media
boundaries but have a fundamental basis in processing human language and
artifacts.  

OBJECTIVES

Research in this area is in the formative stages and is just now beginning to
address difficult fundamental problems, such as the representation and
reasoning about spatial and temporal media.  IJCAI-95 presents an opportunity
to move toward an integrated view of media processing by addressing a
specific technical area:  multimedia information retrieval.  The language
processing, speech processing, image/video processing and spatial/temporal
reasoning communities have much to offer and much to learn from one another. 
The purpose of this workshop is to bring together researchers and
practitioners to report on current advances in multimedia information
retrieval systems and their underlying theories, to foster scientific
interchange among these individuals, and as a group to evaluate current
efforts and make recommendations for future investigations.  A report on the
workshop will be submitted to appropriate magazines (e.g., AI Magazine, IEEE
Expert, ACL's FINITE String).  An edited collection to include the best
papers is planned.   

ISSUES

Submissions (papers and/or video/computer demonstrations) are invited on
original research in all aspects of multimedia information retrieval,
including, but not limited to:

* Content-based analysis and retrieval of multimedia sources (e.g., parsing
   and integrating text, imagery, maps, audio, video) 
* Application of speech, language, and image processing methods and
   techniques to multimedia (e.g., signal analysis, parsing, generation,
   discourse and user modeling)
* Multimedia browsing/visualization tools and cross-media query 
   (e.g, visual, linguistic, and auditory) 
* Multimedia document/presentation design and display
* Tailoring multimedia interaction to particular users, tasks, and contexts
* Intra- and inter-media representation languages
* Architectures for multimedia information retrieval 
* Evaluation methods and metrics for multimedia information retrieval
* Psychoperceptual and cognitive issues in multimodal information retrieval
* Control of user's attention, tension, mood, and sense of continuity by 
   use of appropriate sound, color, and editing 
* Innovative applications of multimedia information retrieval

SUBMISSIONS

Interested participants should e-mail (prefered) or forward FIVE copies of a
2,000 to 3,000 word position paper (4-5 pages, double spaced)
addressing a specific intelligent multimedia information retrieval
issue or reporting novel results to:

Mark Maybury, MS-K331, The MITRE Corporation, Bedford, MA 01730 Tel: (617)
271-7230.  [email-masked]

Submissions must be *received* by February 1, 1994.  Please include
name, affiliation, address, phone, and e-mail address.  Video
submissions should be complemented with a written abstract or position
paper.  Criteria for selection will include clarity, orginality,
relevance, and significance of results.  Attendance at the workshop
will be limited to approximately 30 participants.  All participants must 
register with the main IJCAI conference.  The IJCAI WWW home pge is    
http://ijcai.org/.  

ORGANIZING COMMITTEE

Mark Maybury (chair) The MITRE Corporation, Bedford, MA 
  ([email-masked])
Bill Hefley, Software Engineering Institute, Carnegie Mellon Univ. 
  ([email-masked])
Peter Schauble, Swiss Federal Institute of Technology, Zurich 
  ([email-masked])
Alex "Sandy" Pentland, MIT Media Lab ([email-masked])
Stephen Smoliar, Inst of Systems Science, Univ Singapore, 0511 
  ([email-masked])
Oliviero Stock, IRST, Italy ([email-masked])
Wolfgang Wahlster, DFKI, Germany ([email-masked])
Kent Wittenburg, Bellcore ([email-masked])
Kazuo Tanaka, NTT, Japan ([email-masked])
Philippe Aigrain, IRIT, France ([email-masked])

IJCAI SCHEDULE 

December 1, 1994	-- Call for participation
February 1, 1995	-- Submission deadline 
February 2, 1995	-- Allocation to reviewers
February 30, 1995	-- Notification of acceptance (via e-mail)
March 15, 1995      	-- Camera-ready workshop paper due
April 5, 1995		-- Workshop schedule/participants finalized
May 5, 1995             -- Workshop notes due to CRC
???, 1995		-- IJCAI early registration deadline
???, 1995     		-- IJCAI late registration deadline
August 19, 20, or 21    -- Workshop
November 1, 1995	-- Workshop report to Workshops Chair

----------------------------------------------------------------------

Date: Fri, 23 Dec 94 5:56:40 EST
From: Gerd Beling <[email-masked]>
To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked] (David A. Borman), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng
Content-Length: 847

hello again,
after having been switched from charm to snap.org, here again some
thoughts
concerning the pseudo-header:
a) It is included in TCP/IPv4 to protect TCP against misrouted IP
packets.
Now, given that the IP-header is protected by a checksum itself, how
likely is the case that a packet is misdelivered with a correct
IP-checksum?
Is that not a little bit overengineered nowadays with better networks?
Did anybody try to find out how many packets werde tossed because the
pseudo-header detected an error which IP could not find (and TCP anone
woukd have detected)?
b) If the pseudo-header has to stay for some reasons I prefer the precise
architectural decoupling of the protocols TCPnG and IPv6, i.e. make the
pseudoheader part an end2end-option within IPv6 and do NOT include it
additionally into the TCPnG checksum
regards gerd beling

From: [email-masked]
Date: Fri, 16 Dec 94 14:04:37 EST
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Community Networking Call For Participation
Content-Length: 5473

=============================================================================
                        Call for Participation
=============================================================================

              SECOND INTERNATIONAL WORKSHOP ON COMMUNITY NETWORKING

                   INTEGRATED MULTIMEDIA SERVICES TO THE HOME

                                June 20-22, 1995
                           Princeton, New Jersey, USA

                  Sponsored by the IEEE Communications Society
   		  In collaboration with ACM SIGCOMM*

Community networking concerns the network infrastructures that will
bring integrated multimedia services to home users.  Community networking
differs in many ways from enterprise networking in its services,
technologies, and economics.  In contrast to enterprise networking
applications, community networking services will not necessarily be work
oriented and will range from entertainment to shopping to information
services.  At present, community networking technology is driven by the
requirements of video-on-demand, most notably high bandwidth (compared
to narrowband), bandwidth asymmetry, and the delay-jitter constraints
imposed by today's limited-storage TV set-top devices.  As various other
services develop, community networking will evolve to include integrated
multimedia communication and user-to-user applications.  Community
networking must also provide access to resources located outside the
community, in an increasingly global repository of information of every
conceivable type.

This workshop will give researchers and professionals the
chance to share their views and advance the state of the art in this
field.

RELEVANT AREAS: Contributions are encouraged in the five areas listed
below with relevant topics:

    1. APPLICATIONS AND REQUIREMENTS: types of applications; coding;
    set-top operating systems; QoS networking requirements
    (symmetric/asymmetric bandwidth, delay, and losses); security
    and privacy; service models; user interface and navigation
    facilities.

    2. LOCAL DISTRIBUTION TECHNOLOGY: topology; fiber/cable/UTP/wireless;
    modulation, bandwidth allocation; MAC (reverse channel); role
    of ATM; dependencies on equipment/network in the home (e.g.,
    TV set-top).

    3. ADDRESSING, SIGNALING, AND UPPER-LAYER PROTOCOLS:  local
    vs.  global addressing; the service provider view vs. the common
    carrier view: the video-dialtone gateway; role of B-ISDN
    protocols; network- and transport-layer protocols; network
    management; APIs.

    4. INTERNETWORKING AND ARCHITECTURE: the gateway: accessing
    other networks (data, telephone); server placement and network
    optimization; the regional distribution centers; testbeds;
    network traffic models; network cost structure and its implications
    on service pricing; medium- and long-term network evolution;
    the impact of regulatory constraints.
 
    5. COMMUNITY ASPECTS, OPPORTUNITIES FOR GROWTH: the success of
    community networking depends of the degree to which it meets community
    needs and invites the full participation of community members; community
    needs, desires and aspirations; networking approaches that have worked
    well in the past and others that have not; obstacles to success that
    need to be overcome. 

INSTRUCTIONS FOR SUBMITTING ABSTRACTS:  Please send via electronic
mail a detailed abstract (up to 3 pages in ASCII or PostScript)
describing a position statement in one of the areas above to

                [email-masked]

Note that submissions longer than the limit above will not be reviewed.
Only if electronic submission is impossible, a hardcopy version may be
sent to:
                Joel Winthrop
                AT&T Bell Laboratories
                101 Crawfords Corner Rd., RM 1K-306
                Holmdel, NJ 07733, USA

Participation in the workshop will be by invitation only based on
the Program Committee's review of position statements.  Some of the
authors will be asked to submit papers and to present them during the
workshop.  Workshop size limitation may preclude attendance of all
authors of multi-author abstracts.

DATES:
    Deadline for submitting abstracts . . . . . . . . March 17, 1995
    Acceptance notification . . . . . . . . . . . . . April 17, 1995
    Papers due (limited to 8 pages) . . May 19, 1995

PROGRAM COMMITTEE:

Program Chair:
    Joel Winthrop         AT&T Bell Labs, Holmdel, New Jersey
 
Publication Chair:
    Vince Lesch           AT&T Bell Labs, Holmdel, New Jersey

Committee Members:
    Joydeep Bose          National Computer Board, Singapore
    Jurgen Brommelhoff    Digital Equipment Corporation
    G. Keith Cambron      Pacific Bell
    Andrew Davidson       Phillips Interactive Media of America
    Jeff H. Derby         IBM Corporation
    Alexander D. Gelman   Bellcore
    Riccardo Gusella      Hewlett-Packard Laboratories, Palo Alto, California
    Gordon Kerr           BT Labs
    Andrew Laursen        Oracle Corporation
    Andrew Lippman        MIT, Media Lab
    Tetsuya Miki          NTT Transmission Systems Laboratories
    Mario Morino          Morino Foundation  
    Martin De Prycker     Alcatel Bell Telephone, Antwerp, Belgium
    David Skellern        Macquarie University, Sydney
    Albert J. Stienstra   Philips Research
    Mario P. Vecchi       Time Warner Cable, Inc.
    William E. Wall       Scientific-Atlanta, Inc.

* Approval Pending

From: [email-masked]
Date: Wed, 14 Dec 94 17:05:19 EST
To: [email-masked]
Subject: CFP: ACM MULTIMEDIA'95
Content-Length: 6907

                        ACM MULTIMEDIA'95
                        November 5-9, 1995 
		    Hyatt Regency (Embarcadero)
			San Francisco, CA

  THE THIRD ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION

      	Sponsored by the ACM SIG Multimedia, SIGCHI, SIGGRAPH,
	SIGBIT, SIGOIS, SIGIR, and IEEE Communications Society

                  PRELIMINARY CALL FOR PARTICIPATION

Multimedia can substantially improve communication between information
providers and consumers by making it more effective and more engaging.
ACM Multimedia'95 will provide an international forum for papers, panels,
videos, demonstrations, courses, workshops, and exhibits focusing on all
aspects of this multi-disciplinary field: from underlying technologies
to applications and issues, and from theory to practice. We invite your
participation.

Topics include, but are not limited to: applications in education,
entertainment, government, medicine, etc.; collaboration environments;
databases; digital libraries; distributed systems; documents and
authoring; hardware and architectures; image, video and audio
compression techniques; information retrieval; interactive television;
media integration and synchronization; networking and communication;
operating system extensions; programming paradigms and environments;
standards and legal issues; storage and I/O architectures; tools; user
interfaces; and virtual reality.

Papers
------
Technical papers on completed or in-progress research, innovative
applications, or experience with multimedia systems are solicited.
Submissions must use a typeface no smaller than 10 point, double sided
if possible, and be no longer than 12 pages including figures, tables, 
and references. Where applicable, prototype demonstrations or videotape 
presentations are encouraged to supplement the talks. Submit complete
papers to: Polle Zellweger, Program Chair.

Outstanding papers on different areas of multimedia will be given awards.
Papers with a student as the primary author will enter a student paper
award competition. A cover letter must identify the paper as a candidate
for the student paper competition. Selected papers will be forwarded to
ACM/Springer-Verlag Multimedia Systems, Communications of the ACM,
IEEE/ACM Transactions on Networking, or ACM Transactions on Information
Systems.

Panels
------
Panels are solicited that examine innovative, controversial, or
otherwise provocative issues of interest. Proposals should be limited
to 2 pages, plus a biography of at most one paragraph for each
participant. Submit panel proposals to:  Fillia Makedon, Panels Chair.

Videos
------
Videos of innovative multimedia technology  should be 5-8 minutes long,
in NTSC format, and accompanied by one copy of a 1-2 page description
of the material shown in the video. Submit videos to:  Gil Cruz, Videos 
Chair.

Demonstrations
--------------
We solicit demonstrations of working systems in technical and artistic
categories. Submissions (at most 2 pages) should include a description of
the exhibit, demo requirements, a biography, and a single VHS NTSC video.
Submit demonstrations to: Tom Little, Demonstrations Chair. 

Courses
-------
There will be a series of 1/2-day tutorial courses, focused on issues
relevant to researchers and/or practitioners of multimedia technology.
Proposals (at most 5 pages) should include a description of the subject
matter and brief biographical sketches of the instructors.  Evaluation
of proposals will be based on expertise and experience of instructors,
relevance of subject matter, and the use of multimedia technology in the
presentation. Submit tutorial proposals to: Sorel Reisman, Tutorials 
Chair.

Workshops
---------
Workshops preceding the conference will allow participants to exchange
ideas on a topic. Workshop results and issues will be integrated into the
main body of the conference. Submit workshop proposals to: Ephraim 
Glinert, Workshops Chair.

Exhibits
--------
ACM Multimedia'95 offers a unique opportunity for vendors and publishers
to exhibit and demonstrate multimedia products. For more information,
contact Don Collier, Exhibition Manager.

=============

Authors of accepted submissions will be required to submit both a camera-
ready copy of the manuscript for the printed proceedings and an electronic 
copy for the CD ROM proceedings.

Authors must assign copyright to ACM as a condition of publishing their
work in the proceedings. An author who embeds an object, such as an art
image, copyrighted by a third party is expected to obtain that party's
permission to include the object with the understanding that the entire
work may be distributed as a unity to ACM members and others.

Up-to-date information about ACM Multimedia'95, including a more detailed
version of this call, can be found on the World Wide Web at
http://acm.org/MM95/.

IMPORTANT DATES 
---------------
Six copies of all submissions due: March 29, 1995. Notification of 
acceptance: June 30, 1995. Submissions in final form due: August 11, 1995.

			CONFERENCE COMMITTEE
			--------------------
General Chair:				Treasurer:	     
R.B. Allen, Bellcore		 	M. Brown, DEC	    

Electronic Information:			Networking:
H. Zhang, CMU			 	G. Paxinos, Metro Link

Electronic Publishing:			Proceedings:
R. Phillips, LANL		 	S. Heller, GWU

Publicity:				European Liaison:
R. Mehrotra, UM-St. Louis 		C. Thanos, Consiglio Nazionale
					delle Ricerche (Pisa)

Steering Committee Co-Chairs:
S. Bulick, US WEST
A. Kuchinsky, Hewlett Packard

PROGRAM CHAIR:				PANELS CHAIR:				
Polle Zellweger		 		Fillia Makedon
Xerox PARC			 	Dept. of Math and Computer Sci.
3333 Coyote Hill Road		      	Dartmouth College
Palo Alto, CA 94304 USA	 		6211 Sudikoff Laboratory, Room 109
[email-masked]		 	Hanover, NH 03755-3510 USA
Phone: +1-415-812-4426		 	[email-masked] 
				 	Phone: +1-603-646-3048
				 	
VIDEOS CHAIR:				DEMONSTRATIONS CHAIR:
Gil Cruz, R. Hill		 	Tom Little
MRE-2B280			 	Dept. of Elec. and Computer Engr.
Bellcore				Boston University	
445 South Street		 	44 Cummington St.
Morristown, NJ 07960 USA	 	Boston, MA 02215 USA
{gil,[email-masked] 	 		[email-masked] 
Phone: +1-201-829-5212		 	Phone: +1-617-353-9877

TUTORIALS CHAIR:			WORKSHOPS CHAIR:
Sorel Reisman			 	Ephraim Glinert
Dept. of Computer Science	 	Dept. of Computer Science
California State University	 	R. P. I.
Fullerton, CA 92634 USA	 	 	Troy, NY 12180 USA
[email-masked] 	  	[email-masked]
Phone: +1-714-773-3325		 	Phone: +1-518-276-2657

EXHIBITS CHAIR:				EXHIBITOR INFORMATION:	
Brent Hailpern			 	Don Collier
IBM T.J. Watson Res. Ctr.	 	DC Expositions, Inc.
30 Sawmill River Roada		 	555 Republic Drive, Suite #316
Hawthorne, NY 10532 USA	 	 	Plano, TX 75074 USA
[email-masked]		 	[email-masked]
Phone: +1-914-784-6821		 	Phone +1-214-423-4286

       1995 ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION

Date: Wed, 7 Dec 1994 23:10:29 -0800
From: [email-masked] (Erik Nordmark)
To: [email-masked]
Subject: Re: Some Thoughts on TCPng
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 836

> The P-hdr is used in TCP to ensure correct delivery.  I fail to see
> how any other HLP protocol could do that differently.  I thought
> Sean's idea was rather clever.

Protocols like VMTP that include globally unique indentifiers
for the source and destination endpoints (if I recall correctly
they were called Entity Identifiers in VMTP) will be able to detect
that a packets has been delivered to the wrong host without relying 
on the IP addresses not being modified in flight.
Thus such protocols have no need to include the IP source and destination
in the pseudo header checksum.

Also, protocols that include their own length field have no need to include
the packet length in the P-hdr checksum.

However, the protocols I'm aware of either have the TCP/UDP P-hdr definition
or do not have a pseudo-header at all.

   Erik

Date: Wed, 7 Dec 1994 18:20:10 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 583

  *> 
  *> Sean,
  *> 
  *> > I don't see how the higher level protocol would ever affect 
  *> > the pseudo header.
  *> 
  *> The pseudo-header is used by the higher-layer protocol to detect errors
  *> in those fields of the IP header upon which it depends for its correct
  *> operation.  It is not necessarily the case that all higher-layer protocols
  *> depend on the same set of IP fields.
  *> 

Steve,

The P-hdr is used in TCP to ensure correct delivery.  I fail to see
how any other HLP protocol could do that differently.  I thought
Sean's idea was rather clever.

Bob

To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng 
Date: 	Wed, 7 Dec 1994 15:13:44 PST
Sender: Steve Deering <[email-masked]>
From: Steve Deering <[email-masked]>
Content-Length: 561

Sean,

> I don't see how the higher level protocol would ever affect 
> the pseudo header.

The pseudo-header is used by the higher-layer protocol to detect errors
in those fields of the IP header upon which it depends for its correct
operation.  It is not necessarily the case that all higher-layer protocols
depend on the same set of IP fields.

By the way, your desire that the pseudo-header rules for TCP be specified
in the IP spec has been satisfied, in IPv6 (as it was in SIP and SIPP
before it) -- please see draft-hinden-ipng-ipv6-spec-00.txt.

Steve

From: "Sean O'Malley" <[email-masked]>
Subject: Re: Some Thoughts on TCPng
To: [email-masked] (David A. Borman)
Date: Tue, 6 Dec 1994 16:08:09 -0700 (MST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 2189

> 
> Sean,
> 
> > The TCP spec currently references the IPv4 address  
> > so any change to pseudo header will require a modification to the 
> > TCP spec. My argument is that the world would be a better place if 
> > the definition of the pseudo header was left up to the lower level
> > protocol. I included the implementation detail to show what would 
> > be entailed by this change. Also since I do not know the BSD source that 
> > well I have know idea how hard this approach would be to support in
> > the BSD TCP implementation. 
> 
> Sure, moving the definition of the pseudo-header to the IP document
> would mean that the TCP spec wouldn't have to be modified every
> time the IP layer is changed, but that then means that the IP
> document has to be modifed every time a new transport is added
> above IP that uses a pseudo-header.  Even if it is the same
> as other protocols, (UDP and TCP have the same pseudo-header),
> it still would have to be iterated.  I don't see much advantage
> in terms of having to modify specs to argue one way or the other.

Ah I see where we differ. Since the contents of the pseudo 
header are purely a function of the IP header and semantics 
I think you could define it once and never do it again. 
I don't see how the higher level protocol would ever affect 
the pseudo header. Higher level protocol would have to know if 
it wanted to include pseudo header information in its checksum 
but it would never have to know what that pseudo header looks
like. If the interface to all protocols that provide pseudo 
headers is the same you would not even need to change the 
code. 

You think we would have to revisit it every time we add a 
new higher level protocol. Why do you believe this is true? 

The fact that you think this is possible:

> If the pseudo-header is to be considered part of the IP layer,
> then I would argue that what you really want to do is to eliminate
> the pseudo-header from the TCP (and UDP) checksum, and add an
> end-to-end IP option that contains a checksum over the fields
> in the IP header that should not change from end-to-end. 

argues to me that the higher level protocols need not be 
involved.

Sean

Date: Tue, 6 Dec 94 16:56:55 CST
From: [email-masked] (David A. Borman)
To: [email-masked]
Subject: Re: Some Thoughts on TCPng
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 2541

Sean,

> The TCP spec currently references the IPv4 address  
> so any change to pseudo header will require a modification to the 
> TCP spec. My argument is that the world would be a better place if 
> the definition of the pseudo header was left up to the lower level
> protocol. I included the implementation detail to show what would 
> be entailed by this change. Also since I do not know the BSD source that 
> well I have know idea how hard this approach would be to support in
> the BSD TCP implementation. 

Sure, moving the definition of the pseudo-header to the IP document
would mean that the TCP spec wouldn't have to be modified every
time the IP layer is changed, but that then means that the IP
document has to be modifed every time a new transport is added
above IP that uses a pseudo-header.  Even if it is the same
as other protocols, (UDP and TCP have the same pseudo-header),
it still would have to be iterated.  I don't see much advantage
in terms of having to modify specs to argue one way or the other.

If it is a question of modifying documents, then perhaps there
should be a TCP spec that doesn't specify a pseudo header, and
then there are individual documents that specify the TCP pseudo
header for each of the underlying protocols that TCP can be
layered on.  Then the TCP spec doesn't have to be modified
each time someone wants to run it on top of a new network
layer.

But whether the actual text is in the same document as the TCP
specification or in a separate document, it is still part of
the Transport layer;  it is not part of the layer below it.

If the pseudo-header is to be considered part of the IP layer,
then I would argue that what you really want to do is to eliminate
the pseudo-header from the TCP (and UDP) checksum, and add an
end-to-end IP option that contains a checksum over the fields
in the IP header that should not change from end-to-end.  (The
same fields in the current TCP and UPD pseudo-headers.)  If
an IP packet arrived with the end-to-end checksum option and
the checksum was wrong, the then IP layer would toss the packet
without ever handing it up to the next layer.  On output TCP
(and UDP) would instruct the IP layer to insert the pseudo-header
checksum option.  You might also want the receiving TCP to
be able to toss any packets that it receives that did not
contain the end-to-end pseudo-header checksum.

But I think that that is more than what needs to be done.
I'd say we just need to define a new TCP pseudo-header for
IPv6/TCP.

			-David Borman, [email-masked]

From: "Sean O'Malley" <[email-masked]>
Subject: Re: Some Thoughts on TCPng
To: [email-masked] (David A. Borman)
Date: Tue, 6 Dec 1994 14:26:02 -0700 (MST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 3107

> 
> The TCP pseudo-header
> 
> In Sean's message below, I don't entirely agree with his
> reasoning.  There seems to be a bit of mixing of the definition
> of the TPC pseudo-header and the implementation of that
> definition.  The discussion in the IETF should be on the
> definition, not on the implementation.  Of course, you would
> be foolish to not consider the implementation ramifications
> of a particular definition of the pseudo-header, but the
> definition should just state what fields of the IPv6 header
> are included in the TCP pseudo-header for IPv6/TCP.  Whether
> the implementation does the pseudo-header checksum at the
> IPv6 layer and passed up that checksum to TCP, or whether
> it lets the TCP layer do the checksum of the pseudo-header
> is just an implementation detail, not an issue of what the
> TCP pseudo-header should look like.

The effect upon the definition of TCP would be to move the 
follow paragraph from the TCP spec to the IP spec. (retroactively 
in the case if IPv4).

    The checksum also covers a 96 bit pseudo header conceptually
    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.

                     +--------+--------+--------+--------+
                     |           Source Address          |
                     +--------+--------+--------+--------+
                     |         Destination Address       |
                     +--------+--------+--------+--------+
                     |  zero  |  PTCL  |    TCP Length   |
                     +--------+--------+--------+--------+

and provide the following modification:

  Checksum:  16 bits

    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.

    The checksum also covers a pseudo header defined by the protocol 
    configured below tcp. 

You would also need to add some information to the lower level interface
section of the TCP document.

The TCP spec currently references the IPv4 address  
so any change to pseudo header will require a modification to the 
TCP spec. My argument is that the world would be a better place if 
the definition of the pseudo header was left up to the lower level
protocol. I included the implementation detail to show what would 
be entailed by this change. Also since I do not know the BSD source that 
well I have know idea how hard this approach would be to support in
the BSD TCP implementation. 

Sean O'Malley

To: "David A. Borman" <[email-masked]>
Cc: end2end-interest <[email-masked]>, nsrg <[email-masked]>, sean <[email-masked]>, tcplw <[email-masked]>
From: Robert Ullmann <[email-masked]>
Date:  6 Dec 94 15:19:29 ES
Subject: Re: Some Thoughts on TCPng
Content-Length: 24

You might read RFC1475.

Date: Tue, 6 Dec 94 13:11:38 CST
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng
Content-Length: 16632

I'm including the [email-masked] mailing list in this reply, so
for those on the tcplw mailing list I've included Sean's message
below.

There are a couple of points I'd like to make about TCPng.

First, there are two seperate issues that I'd like to emphasize,
and I hope that the discussion at the BOF will reflect this.

	1) Changes need to be made to the TCP pseudo-header
	   to allow TCP to run over IPv6.
	2) *Any* changes to the TCP header means it is a new
	   version of the TCP header, and it needs a new protocol
	   number.  It doesn't matter whether you are talking
	   about TCP/IPv4 or TCP/IPv6.

>From an implementation standpoint, if TCP is going to change,
there are those who argue that since we are going to be upgrading
to IPv6 anyway, that is a good time to change TCP.  I understand
this argument, but I can't overstate it enough that this is
strictly an *implementation* detail.  If the TCP header over
IPv6 is not the same TCP header over IPv4, then it really is
a new version of TCP that requires a new IP protocol number.

If we do a new rev of TCP, then there are four combinations:
IPv4/TCP, IPv4/TCPng, IPv6/TCP and IPv6/TCPng.  Perhaps people 
don't want to have to support all 4 combinations, and that is
fine.  But there are 4 combinations, and discussion should
keep this in mind so that we don't confuse a transition from
IPv4 to IPv6 with a transition from TCP to TCPng (assuming that
there is going to be a TCPng).

The TCP pseudo-header

In Sean's message below, I don't entirely agree with his
reasoning.  There seems to be a bit of mixing of the definition
of the TPC pseudo-header and the implementation of that
definition.  The discussion in the IETF should be on the
definition, not on the implementation.  Of course, you would
be foolish to not consider the implementation ramifications
of a particular definition of the pseudo-header, but the
definition should just state what fields of the IPv6 header
are included in the TCP pseudo-header for IPv6/TCP.  Whether
the implementation does the pseudo-header checksum at the
IPv6 layer and passed up that checksum to TCP, or whether
it lets the TCP layer do the checksum of the pseudo-header
is just an implementation detail, not an issue of what the
TCP pseudo-header should look like.

TCPng

I don't take lightly discussing changing the TCP header,
which requires a new protocol number for TCPng.  But there
are some issues with the current TCP that cannot be resolved
cleanly without doing a new rev of TCP.  Here's my list:

	1) Size of port numbers
	   The main arguement that I have seen for changing
	   the size of the port numbers is for transactional
	   processing.  Bob's current draft of T/TCP does
	   not require larger port numbers.  So, I don't have
	   any reason to increase them.

	2) 32 bit vs 16 bit window field
	   The negotiation of the tcp window shift option
	   is required to happen during the exchange of the
	   SYNs.  Once this happens, it cannot be changed
	   for that connection.  Whether an implementation
	   initializes this based on the buffer size that
	   the user is using or an explicit command from
	   the user, it has to be set up before the connection
	   is established, and gotten correct.

	   In the typical BSD implementation, it is /etc/inetd
	   that establishes inbound connections, and for rcp
	   /etc/inetd just runs /etc/rshd, which then runs
	   /bin/rcp, which is finally where the knowledge is
	   about the size of buffers that will be used.  But
	   by the time you get there, the window shift is
	   already fixed.

	   Expanding the window field to 32 bits eliminates
	   the need to determine the window shift value before
	   the connection is established.

	3) TCP option space.
	   The main reason that selective ACKs have not
	   been finalized is arguments over how the bits
	   should be layed out in the option to maximize
	   the number of sacks that can be encoded in the
	   limited option space.  Expanding the TCP offset
	   field would eliminate that issue.  Along with
	   64 bit alignment, this field should be changed
	   to be in terms of 64 bit words, instead of 32
	   bit words.

	4) 32 bit vs 64 Sequence space, and Timestamps.

	   These are two issues that need to be thought about
	   at the same time.  In the current TCP extensions,
	   the Timestamps are used by the PAWS mechanism to
	   keep sequence wraparound from missing the detection
	   of old packets.  An alternative way to do this is
	   to expand the sequence space to 64 bits.  Both
	   will work.  However, the Timestamps are very
	   useful for allowing much better RTT estimations,
	   and allows one to eliminate the need for the Karn
	   algorithm when doing RTT measurements.  When using
	   Timestamps for RTT estimation, the worst case
	   scenario is equal to the best case scenario in
	   the typical BSD implementation using the Karn
	   algorithm.  In the worst case scenario for the
	   typical BSD/Karn implementation, you never get
	   a valid RTT measurement.

	   If one is going to change TCP, then I would argue
	   very strongly that the Timestamps should be made
	   part of the fixed TCP header.  Because of the PAWS
	   mechanism, also expanding the sequence space to
	   64 bits would be redundant.

	5) Urgent pointer

	   The TCP urgent pointer is not used very often, and
	   it takes up space in the fixed TCP header.  It would
	   be trivial to remove it (and the URG bit) from the
	   fixed header, and replace it with a TCP Urgent option.

	6) 64 bit alignment

	   If TCP is changing, then the header should be made
	   to be 64 bit aligned, just as IPv6 is 64 bit aligned.

If you add the Timestamp options, remove the Urgent pointer
and expand the Window to 32 bits, you wind up with a header
that is not aligned on a 64 bit boundry.  Making it 64 bit
aligned introduces a "unused" 32 bit field.  There are several
things that could be done:
	1) If the port numbers are expanded to 32 bits, then
	   that would eat up the extra 32 bits.
	2) Leave the urgent pointer in the fixed header, as
	   a 32 bit field, and put back the URG bit.
	3) Allow options to begin in the Unused field, which
	   would require either:
	   1) Add an OPT flag to indicate that there are
	      TCP options.
	   2) Allow the Data Offset to point into the
	      fixed header, which would require:
	      1) The offset is in terms of 32 bits words.
	      2) The offset must be even, except that
		 it could be 7, in which case there are
		 no options, and the real data offset is

Option 3.2 is really ugly, and I don't like it.
Option 3.1 has the nicety that when doing TCP header prediction,
you can check for the existance of options along with the checks
for the other bits, without having to do a seperate check of
the data offset field.
Option 2 allows TCP header compression to compress out the
urgent pointer.
Option 1 is only ok if there is a good reason to expand the
size of the port numbers.

My order of preference would probably be #2, then #1, then 3.1

Using option 2, leaving in the urgent pointer, yields:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|         Source Port           |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Window                             |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+                        Sequence Number                        +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     Acknowledgment Number                     +
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Timestamp Reply                        |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|     Data      |   |U|A|P|R|S|F|                               |
|    Offset     |MBZ|R|C|S|S|Y|I|           Checksum            |
|               |   |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Urgent Pointer                         |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                                                               |
+-+-+-+-+-+-+-+-+            Options            +-+-+-+-+-+-+-+-+
|                                                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
:                                                               :
:                             data                              :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So, this new proposed version addresses:
	1) 64 bit alignment
	2) Additional TCP option space
	3) Full 32 bit window at all times.
	4) Manditory inclusion of Timestamps.

Note that this is not the same as what I mailed out in my
NTCP proposal a while back.

I was under the impression that the TCPng BOF was going to
be scheduled to be multicast, but I just checked the multicast
guide and it is not listed.  So, since I'm not in San Jose,
you'll have to have the discussion without me.

			-David Borman, [email-masked]

P.S:
In regards to Sean's last question about IPv4/TCP and IPv6/TCP
interoperability:

Yes, an IPv4/TCP and an IPv6/TCP can interoperate iff the TCP
pseudo-header is chosen properly.  The IPv4 host will only be using
IPv4 addresses, which get mapped into an IPv6 address format that
was specifically chosen so that the checksum value of the 32 IPv4
address and the checksum of the 128 bit IPv6 address that it is
mapped to are identical.  To make this work then requires that the
IPv6/TCP pseudo-header will have to be exactly the source and
destination IPv6 address, the TCP protocol number, and the TCP length.

> From [email-masked] Sat Dec  3 05:12 CST 1994
> Date: Fri, 2 Dec 1994 11:04:24 MST
> From: "Sean O'Malley" <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: Some Thoughts on TCPng
> Content-Length: 5946
> 
> 
> I thought I would get the ball rolling for next weeks 
> TCPng BOF at IETF. After thinking about it for 
> a couple of days I could not come up with any convincing 
> reason to change TCP. There are three basic reasons people 
> are proposing TCPng.
> 
> 1. IPng Pseudo-Header
> 2. Clean up the TCPLW option + header
> 3. Add features like transactional TCP and multi-cast TCP
> 
> Problem 1: IPng increases the size of the IP address. Hence 
> putting the current TCP on top of IP creates problems because 
> TCP expects a pseudo header with old IP style addresses.
> 
> Problem 0.9: Unfortunately the pseudo header is not the only 
> problem. The BSD TCP code knows what the IP address looks 
> like and the code is riddled with variables declared to be 
> type IPhost. 
> 
> Solution: 
> 
> The TCP source does not really need to know what the 
> IP address looks like. Most of the uses of the IP host are 
> for debugging purposes. The key use of a variable of type 
> IPhost in our implementation is when constructing a demultiplexing 
> key. The TCP source uses the source field of the IP pseudo 
> header combined with the source and destination port fields
> of the TCP header to demultiplex incoming packets. However 
> this is actually an artifact caused by the fact that our 
> TCP implementation is BSD based. In standard x-kernel protocol
> implementations the lower level session pointer would be 
> combined with the local ports to demux incoming packets. 
> 
> Obviously when a user opens a TCP connection he is going 
> to pass in address information which contains IP addresses.
> The x-kernel participant structure resolves this problem by
> supporting a cheap form of type polymorphism which allows 
> TCP to pop of its ports without knowing what the remainder 
> of the address consists of.  
> 
> Problem 1.0: Ok at this point the only remaining reference 
> to a variable of type IPhost in TCP is in the pseudo header.
> 
> Solution:  
> 
> Eliminate the need for TCP to see the IP pseudo 
> header. IPng should support an operation which takes a 
> a session identifier and a  message length and returns the 
> Internet checksum of the IP pseudo header for a message of that 
> length. Thus TCP gets to checksum the pseudo header without 
> ever seeing it.  
> 
> Discussion: 
> 
> At this point we have an implementation of the standard 
> TCP protocol which can run on top of IP or IPng as 
> long as the implementations of the new IPng and the 
> old IP are changed to support polymorphic address 
> types, session identifiers, and the checksum operation. 
> Furthermore TCP is now immune to any further changes 
> to IP. In fact in the x-kernel such an implementation 
> would be able to run just about anywhere including 
> directly on top of a network driver. 
> 
> The problem here of course is that this is not a small delta 
> off of the existing BSD code and is basically an x-kernel 
> oriented solution. However the only alternate I can think 
> of is to modify the BSD code to handle both IP and IPng 
> host address types. I do not believe that this would be 
> a small delta either. 
> 
> Thus it appears to be possible to solve the problem 
> of the IP pseudo header with changes to the way TCP 
> is implemented rather than the way it is specified.  
> In fact it I find hard to imagine that any fix to 
> the IP pseudo header problem would require a change 
> to the TCP header. It is purely an implementation 
> issue and to the extent it is called out in the 
> TCP spec it is an example of over specification. 
> TCP should specify that the TCP checksum is to be 
> computed over the important fields of the lower 
> level protocols header and leave it up to the lower 
> level protocol to determine what those fields are and 
> leave it up to the implementor as to how this is implemented. 
>   
> Problem 2: The rather ugly header format required to by the 
> large window extensions to TCP. 
> 
> Solution: 
> 
> Who cares? I fought tooth and nail against this format 
> in the TCPLW group. However given that it is a standard I don't 
> think it makes any sense to change it.  Given the power of modern 
> processors there is no way processing the TCPLW format is going 
> to result in a significant performance hit. 
> 
> Axiom: If you are going to change a protocol use a rational 
> header structure, the lack of a rational header structure 
> is no reason (in and of itself) to change a protocol. 
> 
> Problem 3: People want to add functionality to TCP.
> 
> Solution: 
> 
> This is why god invented IP protocol numbers. If you want 
> new functionality write a new protocol. I would argue 
> against people saving an IP protocol number by adding a 
> TCP option. 
> 
> I believe that the only valid reason to add functionality 
> to a protocol rather than creating a new protocol is if 
> the added functionality will result in increased performance for 
> current users of the protocol. For example, many current TCP applications 
> use TCP as a reliable request response protocol. Thus something 
> like transactional TCP might make sense because existing 
> TCP users will benefit from it. On the other hand no one 
> currently uses TCP for multi-cast. Thus I believe reliable 
> multicast is best left to a new protocol. 
> 
> This leaves only two semi-legitimate reasons to change 
> TCP: 
> 
> 1. TCPLW is incomplete and requires selective ACKS 
> which will not fit nicely into the TCP option filed.
> 
> 	The need for selective ACKS is debatable.
> 	If they are needed they might fit in the option 
> 	field.
> 
> 2. TCPLW burns up a significant part of the TCP option 
> field making it more difficult to make further modifications 
> to TCP. 
> 
> 	Since I think the primary use of the TCP option 
>    	field would be to add functionality to TCP 
> 	which really belongs in a new protocol I am not 
> 	sure this lack of room is all for the bad. 
> 
> 
> Perhaps TCP should remain as is. 
> 
> Sean O'Malley
> 
> ps: 
> 
> Does IPng support communication between endpoints where 
> one end is running IP and one is running IPng without the 
> IPng endpoint knowing that the other endpoint is running IP? 
> If so I don't see any good way of supporting an IPng pseudo 
> header.
>