[e2e] Types Of Service

[Bob Braden]

  *> Hi,
  *> 
  *> In the same paper (David Clark's) as that of my previous post, it's stated 
  *> that "The second goal of the Internet architecture is that it should 
  *> support, at the transport service level, a variety of types of service.".
  *> 
  *> However, only TCP, UDP, and RTP (which is built over UDP) come to my mind, 
  *> they don't guarantee any specific type of service (for example, "low 
  *> delay", "high throughput", etc.) by themselves.
  *> 

But in principle, they could.  The original IP specification DID
include a TOS byte with delay and throughput bits.   A transport
protocol could use them (in fact, using UDP, an application could use
them.)  These bits were seldom implemented, however.  (Perhaps if they
had been, we would have had a good enough solution to the QoS problem
to spare us the considerable ongoing pain of int-serv, diffserv, etc.)

One of the surprises to the designers of the TCP/IP protocol suite was
the lack of proliferation of transport protocols.  Until RTP came along,
TCP and UDP were the only members of a family that had been expected
to grow much larger.

  *> Besides that, for example, TCP provides a "realiable" byte stream. However, 
  *> there are some errors that TCP won't catch, so if reliability is a real 
  *> issue, then another layer of error control must be built up on top of TCP.
  *> 

Presumably you are referring to local system errors between TCP and the
applications.  This would ultimately have to be dealt with at the
application layer, of course (see the classic E2E argument paper.)

Or are you referring to the weakness of the TCP checksum?

  *> Have there been any efforts (I *do* think so) in developing transport 
  *> protocols that focus on providing different types of service ("low delay", 
  *> "high throughput", "true (?) reliability", etc. ) ?
  *> 

I would argue that TCP *is* the high-reliability protocol, and UDP is
the low delay transport protocol, and they have been used exactly this
way for 20 years.  There are, however, some other points in this space
that are not covered by these two protocols.

Bob Braden


  *> Pointers to any papers discussing the problems and efforts around this will 
  *> be appreciated, too.
  *> 
  *> TIA,
  *> 
  *> --
  *> Fernando Gont
  *> e-mail: fernando at gont.com.ar || fgont at acm.org
  *> 
  *>