Proposal from a new member of the group

[mogul (Jeffrey Mogul)]

I received this message from Fred Bohle of ACC.  Apparently, he
composed his proposal without knowing of the activities of our
working group, but he is now on the mailing list and has been
sent a copy of the mailing list log.  I encourage people to read
this in the hopes that there may be some interesting material
to be mined out of it; however, I have already pointed out to
Fred that RFC1063 is pretty darn dead.

-Jeff

------- Forwarded Message

Return-Path: <[e-mail]>
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34)
	id AA17186; Tue, 30 Jan 90 07:51:08 PST
Received: by decwrl.dec.com; id AA13328; Tue, 30 Jan 90 07:50:58 -0800
Received: from SATURN.ACC.COM by salt.acc.com (5.61/1.34)
	id AA02434; Tue, 30 Jan 90 07:51:41 -0800
Received: by saturn.acc.com (5.51/1.28)
	id AA01760; Tue, 30 Jan 90 10:49:12 EST
Date: Tue, 30 Jan 90 10:49:12 EST
From: [e-mail] (Fred Bohle acc_gnsc)
Message-Id: <[e-mail]>
To: mogul
Subject: RFC 1063 working group
Cc: [e-mail], [e-mail]


Jeffery,

	Enclosed is a copy of an RFC I had proposed to Jon Postel.  He referred
it to Noel Chiappa, who referred me to you and your Working Group.  I have asked
my system administrator to send you a request to add us to your mailing list,
so that will come separately.  I did want to show you my idea for implementing
MTU discovery in TCP.  I would like to get a copy of your draft RFC and
also get a copy of your archives for the mtudwg discussions.

	I am in the process of going through ACC's ACCES/MVS code for conform-
ance to the Host Requirements RFC's.  I am also considering including other
enhancements to the product at the same time,  so this is a good time for
me to implement new ideas, or experiment with them.

	I look forward to hearing from you.

Fred.

---------------------cut here--------------------------------------------------
	IP MTU Discovery (RFC 1063) Revisited

	I have a suggestion for implementing and using the IP MTU
Discovery option.  Please consider this as a possible RFC:

1. STATUS OF THIS MEMO

This memo describes a strategy for using the IP MTU Discovery options [1]
from the TCP layer.  This is a proposal for a simple, effective implementation
of this option.  Distribution of this memo is unlimited.

2. INTRODUCTION

The original description of the IP MTU Discovery option requires a considerable
amount of logic in the IP layer to implement.  On one hand, it must be an IP
option for gateways to process it.  On the other hand, it is TCP which
really needs the information in order to set its MSS properly.

With the specifications in the Host Requirements RFC [2], the specification
and processing of IP options from the next higher layer must be available.
Therefore TCP has the ability to specivy the IP MTU Discovery Probe option
(Probe), Process a Probe when received, specify an IP MTU Discovery Reply
option (Reply), and process a Reply when received.

3. IMPLEMENTATION APPROACH.

Combine the sending of the TCP MSS option withe the specification of a
Probe option.  Combine the processing of the MSS option with the processing
of the Probe option and generate a Reply option.  The three-way handshake
of TCP is ideal for piggy-backing this option.

3.1 ORIGINAL-SYN:  In this state the packets sent will have only the SYN
bit and the TCP MSS option is typically sent here.  Add to it a request
for IP to send a Probe option.

3.2 SYN-ACK: In this state an ORIGINAL-SYN packet has been received.
Process the TCP MSS option in the usual way.  When generating the SYN-ACK
packet, the TCP MSS option is typically sent here also. Add to it a
request for IP to send a Reply option using the value from the received
Probe option.  Also add to it a request for IP to send a Probe option.

3.3 ACK-OF-SYN:  This packet will complete the three-way handshake and
establish the session.  Process the received TCP MSS option in the usual
way.  Calculate an MSS value from the MTU in the Reply option, and use
the lesser MSS.  In the ACK-OF-SYN packet, specify a Reply option using
the value from the received Probe option.

3.4 ESTABLISHED STATE: This state will be entered from the receipt of the
ACK-OF-SYN packet.  This packet will contain the Reply option.  Calculate
an MSS value from the MTU and use the lesser MSS.

This mechanism will allow TCP to retransmit if packets are dropped and
still discover the minimum MTU for the session.  It avoids such interface
problems as UDP receiving some of the Reply options, and IP having to
inform TCP of the minimum MTU somehow.  It also removes some complexity
from the IP layer cacheing this information, although this information 
may still be maintained, if desired.

UDP code which uses comparable methods may make similar use of this option.

REFERENCES

[1] Mogul, J., C. Kent, C. Partridge, K. McCloghrie, "IP MTU Discovery
Options", RFC-1063, USC/Information Sciences Institute, Marina del Rey,
CA, July 1988.

[2] Braden, R., Ed., "Requirements for Internet Hosts -- Communication
Layers", RFC-1122, USC/Information Sciences Institute, Marina del Rey,
CA, July 1988.



----------------------cut here---------------------------------------------

------------------------------------------------------------------------
Fred Bohle			EMAIL: [e-mail]
ACC				AT&T : 301-290-8100 
10220 Old Columbia Road
Columbia, MD 21046
------------------------------------------------------------------------




------- End of Forwarded Message