Subject: [Diffserv] basic question!!

From: Kaleelazhicathu R R Kumar <[email-masked]>
Date: Thu, 3 May 2001 16:18:22 +0800 (GMT-8)

There are few things i would like to clarify which is very basic. I am 
not sure if this is trivial.
The following is for an AF traffic.

1) The markers at the gateways basically mark based on the CIR 

which in turn is the sending rate of any flow. This means that when i 

measure the goodput at the receiver , there is every possibility that i 

may get a value which is less than the value which the marker feels 

the flow is having. How do we take care of this discrepancy?? wont 

this cause a problem?? Take the following scenario.
   
   s---->M1--------->n2-------->M2-------->r

taking a very basic topology as shown above,
    if the bottleneck node is n2, then taking the case of TCP flows, the 

marker M1 would be calculating the average rate at the router level 

and it would be a sending rate. The marker M2 would probably reflect 

the congestion at n2 by showing a reduced average rate, but unless 

M1 knows about it, there is very less M2 can do even if it knows that 

the throughput is low. How do we take care of that?? using a 

bandwidth broker to give a feedback to M1 could be useful..but is there
any other provision??

Now taking the case of UDP. Assuming a scenario where i need a 

assured service for a UDP traffic, based on the above topology, if 

there are multiple drops at n2, how will i know this at M1, so that i 

can act accordingly??  M1 will still feel that everything is fine whereas 

M2 would know that the average rate is less. But marking with a high 

priority at M2 wont really help in avoiding the congestion which we 

have at n2. am i missing something?? couldn't these cause a 

problem?? or have we considered about this?? please let me know..

Is there any draft which talks about this??

Renjish.

The best scientist is open to experience and begins with romance -- the
idea that anything is possible. 
--Ray Bradbury   

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Susie Riley" <[email-masked]>
Date: Thu, 3 May 2001 09:06:27 -0400

first of all, if the flow is tcp, the tcp congestion handling algorithm
should naturally throttle the rate of the sender down (as a result of no
ACKs coming back for the lost pkts).

in the udp case, there is no such congestion handling algorithm.  the source
could still keep on sending at its CIR.  as far as i know there is no
feedback mechanism for m1 or the source to know that there's congestion
ahead.  i think the problem might have to be handled administratively.  i
don't think one would want to invent a scheme like ATM's ABR...

susie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Kaleelazhicathu R R Kumar
Sent: Thursday, May 03, 2001 4:18 AM
To: [email-masked]; [email-masked]
Subject: [Diffserv] basic question!!

Renjish.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 03 May 2001 11:06:19 -0400

> The markers at the gateways basically mark based on the CIR

If I understand correctly, you're concerned about the case where
customer traffic is sent out of your network at a lower rate
than the contracted CIR. If this happens, in most cases, 
there might be insufficient capacity on some of the network
links traversed by this particular customer's traffic. In such 
a case, a smarter policer may not be sufficient to address 
the problem without considering other options such as 
traffic engineering or added capacity in the network. 

> Is there any draft which talks about this??

There were at least 2 drafts that I recall that in the area
of congestion feedback for diffserv. One was by 
Shiv Kalyanaraman et al at RPI and the other from 
U of Toronto - Keith Chow et al (I think).

---
Best
Nabil Seddigh
[email-masked]