Subject: Re: interim meetings?

From: [email-masked] (Noel Chiappa)
Date: Fri, 9 Feb 96 11:00:09 -0500

From: Curtis Villamizar <[email-masked]>

    > TCP streams, though, might prefer the equal-treatment choice, because it
    > minimizes reordering and consequent screw-up of retransmission
    > mechanisms.

    just add delay and keep the ordering and be nice to TCP.

I think I detect an assumption here that I wanted to ask about, and see if I'm
totally out of it, or what.

The assumption is that we're designing a system around the current TCP and TCP
algorithms, as our reliable-stream transmission mechanism (i.e. for stuff that
has to get there right, and for which an elastic service is OK). Now, I agree,
that in the short term we need to not screw up TCP badly, as it's extremely
widely deployed and all that. However, I wonder if, in a discussion on
fundamentals, and what is really the ultimate goal, this is a good constraint?

The current TCP mechanisms (such as the single ACK, etc) are, after all,
i) the result of fairly old thinking (which not to say it's wrong, but we have
learned a lot since then), ii) the result of assuming a pure datagram
architecture, etc, etc. (I know there is work going on to consider partial
ACK's, and a bunch of other stuff, but that just ties into my next point.)

Perhaps it would be useful to go back to basic, and ask if, in a world which
has resource allocation and thus complex queueing mechanisms in the routers,
if in the long run the Right Answer is to say that reliable-stream service is
best provided by something somewhat different than the classic TCP mechanisms,
something which is more tuned to a new environment.

To take a wild example (i.e. probably a bad idea, but to give you the flavor
of what I'm talking about in the way of rethinking), perhaps we should provide
reliable-stream service on a base which does reorder packets more commonly (as
a side effect of doing something else better, like realtime traffic), and
change reliable-stream to work well in that environment. This tradeoff would
make sense, for example, i) if the downside to reliable-stream is lower than
the help this provides in doing realtime, or ii) if it results in a better
overall bandwidth for reliable-stream than keeping the minimal-reordering
model for it, or whatever.

Maybe the right answer for reliable-stream is in fact to keep TCP just as it
it, which would seemingly require the current minimal-reordering, but does it
at least bear examining?

    > Implementation questions play a big part in this, too. ... three
    > possible implementations of controlled-load ... they naturally
    > do one or the other of the above over-load actions ... In my view, there
    > will be cases where a particular hardware design can easily implement
    > one but not the other of these behaviors.

    So you provide a poor response to one of the two types of traffic and
    no clue to the end-system that their traffic will be trashed by your
    choice?  Doesn't sound to me like a good design.

Perhaps this is a sign that the definition of "controlled-load" is too broad,
since one could get quite different behaviours from different boxes that have
taken different implementation choices? Maybe a number of different
sub-services could be specified (for queries and description, if not for
requests, since as John points out that would require all switches to provide
multiple mechanisms, although I suppose one could always deny requests that
specify a sub-service one doesn't support), so the end-user can at least know
what behaviour to expect?

    > Considering all this - the fact that different applications might
    > ideally like different over-load behaviors from the service ...
    > mandating just one behavior is going to throw -somebody's-
    > implementation for a loop, I intentionally left the choice unspecified.

    OK. So you didn't finish the job and left a big hole in the spec.

I think John is saying that making a choice is not the best way to tackle
this, especially with little operational or other experience to say what the
best choice is anyway. Perhaps at least allowing switches to specify what
their behaviour will be is a useful middle ground between i) forcing all
switch designers to do it one way, and ii) saying nothing at all?

	Noel

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Feb 1996 13:30:58 -0500

> fundamentals, and what is really the ultimate goal, this is a good constraint

Noel,

I'm sorry.  I didn't realize int-serv was an acedemic exercise.  :-)

Supporting TCP as it now stands is extremely important to Internet
service providers and will be for a long time to come.

> something which is more tuned to a new environment.

If you want to support this *in addition* to excellent support for the
existing TCP behavior, go right ahead.  If you want to support it in
place of excellent support for the existing TCP behavior, forget it.

Curtis