Subject: Re: TCP's handling of IP precedence

From: Vernon Schryver <[email-masked]>
Date: Wed, 15 Sep 1999 13:33:07 -0600 (MDT)

> From: Vern Paxson <[email-masked]>

> ...
> 	5.  6 months later it's discvered that the redefinition causes one
> 	    TCP to send resets.  The email describing this says
>
> 		  > As it turns out, this is an archaically (sp) known
> 		  > problem, with a pre-existing patch.
> 	    
> 	    and elicits a reply:
>
> 		  > MacTCP is *old*, and has many more problems than
> 		  > this.  Please tell your help desks that if they run
> 		  > across users still using MacTCP, that they advise
> 		  > them to upgrade to at least MacOS 7.5.3 (preferably
> 		  > 7.5.5), which is free, and includes Open
> 		  > Transport.

See also the note this morning from someone reporting about what sounds
like the same problem with some Windows TCP code.

If only ancient MacTCP had the problem, you might, but only might get away
with declaring old MacTCP non-conformant.   That is basically what you
are proposing, to break an unknown number of existing implementations and
installations.

> 	6.  The question now is how many significant TCPs are actually
> 	    effected, and, accordingly, how to fix the problem.

Agreed.

However, on general grounds the fait accompli argument is completely
inadmissable.  400 people participating in DiffServ meetings are not a
majority of the IETF, even if majorities mattered, which they don't. 
Even if you accept the history as you have stated it (which I don't quite),
the onus for bearing fixing the problem lies with DiffServe, *NOT* TCP.
If a painless change can be made to TCP, then that would be great, and
would remove the burden from DiffServ.  If there is no painless TCP fix,
then the pain *MUST* be borne by DiffServ.

] From: Vern Paxson <[email-masked]>

] That's the point of Last Call - if you care about where the IETF is going,
] you are supposed to read [email-masked] and see what is being
] proposed.  You don't have to read all the documents, just the ones that
] appear relevant.  The abstract of RFC 2474 is clear that the document is
] about redefining the TOS byte.

That is mistaken in several ways.  Even if the Last Call had said something
about breaking existing TCP, the onus would still be on DiffServ.  However,
given the established IETF culture and expectations, something that talks
about redefining the TOS byte would be assumed by knowledgable people to
upward compatiable and not break existing installations without explicitly
saying so, and not without a lot more main IETF list discussion than
the last call.

By concidence, I had been trying to understand RFC 2474 before all of this
broke, and had assumed the intent of RFC 2474 was to be upward compatible.
The words in RFC 2474 are not entirely clear, but they do promise
significant upward compatibility.  Consider the start of section 4:

  The DS field will have a limited backwards compatibility with current
  practice, as described in this section.  Backwards compatibility is
  addressed in two ways.  First, there are per-hop behaviors that are 
  already in widespread use (e.g., those satisfying the IPv4 Precedence
  queueing requirements specified in [RFC1812]), and we wish to permit
  their continued use in DS-compliant nodes. ...

] > Since getting anything changed during Last Call is at best difficult
]
] The WG raised the issue of what depends on the current structure of the TOS
] byte at length, had considerable discussion, and no one brought up the TCP
] incompatibility.  It's not as though it wasn't high profile - 400+ people
] attend each diffserv meeting.  But even so, it was on the radar as a
] significant issue, and I think it would have been treated very seriously
] as a last call comment.

I am confident of the good intentions of all concerned.  Still, when
balancing painful changes, which sub-community (or if you prefer, chunks
of code) must suffer most of the pain?

] > Instead of requiring changes to an unknown but apparently significant
] > number of existing TCP implementations and literally uncountable TCP
] > installations, why not strengthen the DiffServ words about upward
] > compatibility?
]
] One of the key questions is: is it really a significant number of TCP
] implementations?  That's why this discussion should happen on tcp-impl.

I agree that is a critical question.   The note this morning about
Windows 3.1 was extremely worrisome.

] > If the RFC 1349/RFC 1812 values of the IP TOS byte were
] > required to be get through unchanged (after possibly having been mapped
] > to other values and back again), would any existing combinations of
] > applications and host break?
]
] How do you know what to map them back to?  It's not a one-to-one mapping.

Which map is not 1:1 and does it matter?  Since RFC 2474 defines a lot
more potential behaviors than RFC 1812 and RFCX 1349, you obviously cannot
map DiffServ 1:1 onto RFC 1349.  However, in practice there are only about
3 different RFC 1349 values.  It seems to me that requiring that DiffServ
preserve 3 values would completely would be painless for DiffServ, and
far wiser than declaring that an unknowable number of TCP implementations
and installations non-conformant and requiring them to be changed.

I think the only commonly used RFC 1349 values are 0 (extremely common),
0x10 (minimize delay), and 0x80 (maximize throughput).  See your nearest
BSD source trees.  I found all of those in the first 4.4BSD-Lite CDROM,
and I know that 0x10 has been creeping into other widely used applications,
partly because I've helped push it.

Vernon Schryver    [email-masked]

---

From: venkat venkatsubra <[email-masked]>
Date: Fri, 17 Sep 1999 09:18:15 -0500

The following mail seems to indicate that NCR's MP-RAS
Unix was having similar problem after they made changes
to the Precedence bits handling in tcp input to conform to
RFC 793. They did this change to pass one of the Unix'95
Certification test. Now i think they got rid of this change
(available in a later patch) - or giving the user an option
to turn off/on this behaviour.

> Subject: TOS and PRECEDENCE bits
> From: Bob Walpole <[email-masked]>
> Date: 1998/12/23
> Newsgroups: comp.protocols.tcp-ip

> Here's a specific scenario I have ran into a couple of times.
> By default our TOS field is set to 0.
> Most applications that set the TOS do not set the PRECEDENCE bits
> anyway, at least in my limited experience.
> Is IP allowed to tell TCP to reset the connection if the incoming
> precedence bits do not match those stored in the inpcb for this
> connection?
> What should it do, if anything?
> Is this specified anywhere?
> I have seen precedence bits 110 (when the other interface was X.25) and
> 100 (when the other interface was unkown) in packets from routers. This
> causes the TCP connection to be reset.
> If Iset ip_settos to 0, would it be reasonable to assume I do not wish
> to check the value in the incoming packets?

Venkat