Subject: Re: TCP's handling of IP precedence

From: Joe Touch <[email-masked]>
Date: Wed, 15 Sep 1999 18:23:02 -0700 (PDT)

> From: Alan Hannan <[email-masked]>
> To: Joe Touch <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: TCP's handling of IP precedence
> 
> > Is it the case that Diffserv:
> > 
> > 	- intends these bits to be used for TCP connections?
> 
>   No.
> 
> > 	- intends that they change after a connection is established?
> > 		or would that constitute the need for 
> > 		a TCP extension to renegotiate?
> 
>   Kind of, but not really.

I don't understand how the first question can be 
a "No" and the second question is relevant.

However...

> 
>   Rather, Diffserv intends that they change while the connection is
>   being established.
> 
>   Remember that what happens is that the initiator tries to setup a 
>   tcp session w/ TOS=0; but en route to the receiver, a router
>   changes the DS bits from the original [as specificed by the
>   initiator] to something else.  The receiver then 'plays along'
>   because he doesn't know any better, and the initiator doesn't get
>   back what he wants, so he breaks the connection.
> 
>   Ideally, the 'initiator' would negotiate the TOS w/ the receiver,
>   but this doesn't happen.

Why shouldn't this happen like ICMP redirects or PMTU - some sort
of NACK at the ICMP level to the source?

I.e., "ideally, the initiator would negotiate with the network,
then ask the receiver for something known"...

??

Joe

---

From: Alan Hannan <[email-masked]>
Date: Wed, 15 Sep 1999 19:15:32 -0700

> a "No" and the second question is relevant.

  I think I was focused on the tree instead of the forest.

  Yes, Diffserv intends for these bits to be used to differentiate
  service levels of TCP connections, as a non-specific subset of IP
  traffic.

  I interpreted your question to mean that Diffserv intended the
  bits to be a component of the connection setup.

> of NACK at the ICMP level to the source?

  One reason is that the quality of the traffic is non-relevant to
  the connection; ie; IP is connection-less; so failure to be
  granted a given traffic quality should not inhibit the
  connection, as a function of the protocol.

> then ask the receiver for something known"...

  Yes, this is one approach, but _that_ change to the tcp spec is
  far more reaching than the one we're proposing :-)

  -alan

---

From: Geoff Huston <[email-masked]>
Date: Thu, 16 Sep 1999 14:59:39 +1000

>then ask the receiver for something known"...

Marshall Rose and I wrote a draft along those very lines about
3 years back  - using the PMTU approach to undertake
dynamic discovery of path TOS.

But I note that this approach is not overly compatible with the
current DiffServ architecture, where the DS field can be
arbitrarily changed at any point in the network by any marker
to any value (*).

If you're interested I could dredge the draft up again.

Geoff

(*) One of a number of significant weakness in the DiffServ architecture
as it currently stands - DiffServ still has some ways to go, obviously.