Subject: RE: support for packet drop priority

From: Ram Krishnan <[email-masked]>
Date: Wed, 21 Jan 1998 16:27:01 -0500

-----Original Message-----
	From:	Alessio Casati [SMTP:[email-masked]]
	Sent:	Wednesday, January 21, 1998 12:30 PM
	To:	Steve Deering
	Cc:	[email-masked]
	Subject:	Re: support for packet drop priority

	What I was meaning is that the metering activity may police the
traffic so that excess traffic
	either gets discarded or marked. If it gets discarded, than we
are using you approach (correct me
	if I misunderstand) if it gets marked than we are in a departing
from your approach, but
	here we get the tool to identify bad guys (and that's were I
think you can agree, since
	you tell that you want penalty actions later). Yes, you are
using up some link bandwidth,
	but this use can be economically sustainable depending on the
service the provider is willing to 
	offer. I cannot prevent a provider from deciding to allow this,
if it thinks it's good for 
	itself.

	Ram> How do you police individual TCP applications to determine
discarding/tagging decisions ? How Ram> can they convey traffic flow
characteristics and bandwidth requirements, given that they are 
	Ram> adaptive applications and use up/adapt to whatever
bandwidth is available ? I can understand Ram> policing aggregate
traffic flows from a single customer such that it does not exceed its
bandwidth Ram> contract. Policing guaranteed applications make sense. I
agree that better and more sophisticated Ram> feedback would be more
useful for adaptive applications such as TCP. 

	Ram Krishnan
	Nexabit Networks LLC.
	[email-masked]

---

From: "Alessio Casati" <[email-masked]>
Date: Thu, 22 Jan 1998 17:48:00 +0100

> How do you police individual TCP applications to determine
> discarding/tagging decisions ?

OK, that's the real problem here. You cannot use one tool for everything, and there are
indeed technical problems making policing TCP apps hard. But, although in a BE
environment you may think of TCP as using up as much bandwidth as it can, in A better than BE
you may rate limit it. The problem is there can be retransmissions due to network congestion,
so it would not be fair to count retransmissions of in profile TCP segments into the to be policed 
traffic. An estimate of the wellbehaved connection transmission rate can be determined by the 
knoledge of an estimate of the RTT and the Loss rate (by a well known relationship), but I 
recognize it requires per connection state and the definition of a parameter value, so it's
rather a though best to deal with. But I'm confident a feasible solution to the problem can
be found.

> How can they convey traffic flow
> adaptive applications and use up/adapt to whatever
> bandwidth is available ? 

Look above. We are in a better than BE environment. And yourself recognize that here
below.

>I can understand policing aggregate
> bandwidth  contract. Policing guaranteed applications make sense. I
> agree that better and more sophisticated feedback would be more

alessio