Subject: Re: CM MACROFLOWs versus DiffServ and MPLS

From: Dorothy Curtis <[email-masked]>
Date: Tue, 11 Apr 2000 14:08:02 -0400 (EDT)

Hi -

I am writing in response to your (John Border's) question about how
the CM MACROFLOW concept would fit into the DiffServ world.

In my understanding of the DiffServ world, routers have access to
information, such as a corporate database, that specifies how FLOWs
should be treated.  It seems reasonable to me that the CM could also have
access to such a database and use that information to aggregate
FLOWs into MACROFLOWS and to label FLOWs so that they are processed
appropriately within the network.  (Note: a router might choose not to
trust the CM's aggregation (labelling) and then should make its
independent decisions based on its independent access to information
in a database.)

In the meantime, in the absence of such a database, the CM aggregates
FLOWs into MACROFLOWs based on the destination host of the FLOWs.

Dorothy Curtis
MIT/LCS

   Date: Thu, 06 Apr 2000 16:34:28 -0400
   From: John Border <[email-masked]>
   To: [email-masked], [email-masked]
   CC: [email-masked]
   Subject: CM MACROFLOWs versus DiffServ and MPLS
   References: <[email-masked]>

   The Congestion Manager draft suggests that FLOWs between the same two end
   points which experience identical congestion behavour in the Internet SHOULD
   belong to the same MACROFLOW.  This makes sense.  But, with DiffServ and MPLS
   (and perhaps other mechanisms) now providing the means for FLOWs between two
   hosts to take different paths, it appears difficult for a host to know which
   FLOWs to group together into MACROFLOWs.  Having the host set its own initial
   DSCP would help but would still not completely address the issue.  The latest
   (-02) Congestion Manager draft basically defers this issue as future work. 
   But, the concept of a MACROFLOW seems fundamental to the CM idea so I was
   wondering if you (or someone else on the mailing list who has spent some time
   thinking about this) could summarize the current thinking re this issue in a
   couple of paragraphs...

   John Border
   Hughes Network Systems

---

From: Hari Balakrishnan <[email-masked]>
Date: Tue, 11 Apr 2000 15:46:31 -0400

John,

The fundamental problem behind the issue you bring up is a relatively hard 
research question.  What we are looking for is a way by which the sender (with 
feedback from the receiver) can correctly infer which flows share a common 
path.  What makes this hard is that we would like to do this:
	(i) without any additional traffic, 
	(ii) without really modifying the timing of packet transmissions (e.g., by 
picking packet times so the source looks Poisson), since that may violate 
congestion control and/or lead to degraded performance,
	(iii) fast.  Within a few RTTs,
	(iv) without false negatives.  I.e., two flows shouldn't be deemed in the same 
macroflow if they do not share the same congestion points.

Devising an end-to-end inference scheme that meets all of these conditions is 
an open research problem at this time.  However, I feel comfortable thinking 
that these problems will be solved in some practical (probably non-ideal) way 
before Diffserv gets widely deployed.

***Rant begins here...
As a person who firmly believes in the Internet architecture being a successful 
example of an end-to-end argument, I cannot help but feel that some of the 
practical aspects of diffserv violate this principle.  When the network starts 
doing things to an end-to-end transmission protocol completely unbeknownst to 
that higher layer, it starts to violate some of the assumptions made by that 
layer.  For example, if an ISP sets a DS codepoint at a (congested) edge by 
looking at a TCP port number or URL or some such, we have a potential 
problem---esp. if that ISP sends packets on the same macroflow along different 
(possibly congested) paths.

The application and end-to-end transport layers do in fact know what the 
characteristics of the application are, and it would be good to think in terms 
of a simple in-band signaling mechanism by which application/transport 
characteristics or "desires" are reflected to the network layer to make a more 
informed decision (e.g., about DS codepoint), without an egregious layering 
"violation," and develop an architecture where informed network decisions are 
made to maximize ISP revenue, without ignoring the best interests of the 
end-systems.

One more thing---the CM does have API calls by which an application can declare 
a set of flows to be in the same macroflow (e.g., concurrent HTTP/TCP 
connections).  Unfortunately, it cannot prevent a router downstream from 
looking at the transport layer port number and URL and the phase of the moon :) 
to hash the flow to a certain DS codepoint or a certain link/route.  Unless we 
extend the architecture to include advisory information (which, by the way, is 
also needed for a clean way to ensure that packets belonging to the same TCP 
connections are sent along the same path, for otherwise much hell will break 
loose), I don't see an architecturally elegant solution.

Hari

---

From: Jamshid Mahdavi <[email-masked]>
Date: 12 Apr 2000 12:26:39 -0700

An interesting point to note is that a single TCP connection is
subject to all the same effects.  There could be split routing in the
network; a diff-serv classifier could choose to mark only those
packets fitting in a certain profile; etc.

I don't think we know how to deal with this problem for a single TCP
connection.  We mostly just hope that there isn't split routing, and
if there is, we blame the network for the problem, not TCP.

I suppose that one could argue that having the network decide to give
different classifications to separate TCP connections which are part
of the same application is similarly broken.  (Unless the application
requests it, of course).

--Jamshid

Hari Balakrishnan <[email-masked]> writes:

> ...