Subject: Re: interpretation of bucket size in intserv flowspecs, by hosts

From: Yonadav Perry <[email-masked]>
Date: Mon, 30 Mar 1998 18:57:49 +0300

Yoram,

If a sender sets the bucket size smaller than MTU (or actually max packet
size for the flowspec), it is practically saying "don't hold packets".
Thus, "shape mode" is not required, and any node en-route is free to
discard packets it cannot transmit. (I do believe, however, that even if
the bucket size is 0, any node must be able to keep ONE packet per RSVP
flow until it is that packet's turn to be transmitted.)

Yonadav

At 11:09 27/03/98 -0800, Yoram Bernet wrote:
>Folks:
>
>We've had an interesting issue come up and I'm wondering what your opinions
>are:
>
>In our traffic control module on our hosts, we shape traffic to the token
>bucket parameters advertised in the flowpsec. We have a shape mode and a
>discard mode. In discard mode, we discard everything that is non-conforming.
>In our shape mode, we delay packets (that are submitted by apps), in a
>shaper, and send them to the wire when they become conforming. In this
>manner we provide conformance shaping for the app, so that it can be assured
>that its data is sent to the net in compliance with the token bucket
>parameters advertised in the RSVP/intserv flowspec.
>
>The problem arises when we consider the token bucket size parameter. If the
>token bucket size is smaller than the MTU size. Then, if an app submits a
>packet which is greater than the bucket size, there is nothing that we can
>do in the shaper to make it compliant (since the smallest thing we can send
>on the wire, is a packet, which is greater than the bucket size).
>
>So - we are faced with the option of sending it (not taking the bucket size
>literally) or discarding it (taking the bucket size literally but somewhat
>compromising the application).
>
>If we do not take the bucket size literally, we could at least delay the
>burst so that it conforms with the token rate... It may well be that the
>first hop router will discard it becuase the bucket size is violated. Then
>again - it may not. I need to understand router implementations better. If
>routers always discard, then the right thing to do is probably for us to
>discard.
>
>We're providing flowspec parameters to our apps from codec parameters. I
>wonder if the bucket sizes are intended to represent maximum burst sizes or
>typical burst sizes. I'm wondering what apps generally expect if they submit
>a packet that exceeds the burst size...
>
>How would you all expect hosts to behave?
>
>Yoram
>
>
>
>

Yonadav Perry

Tel:  09-765-2417
Fax:  09-767-8829

[email-masked]

---

From: Yoram Bernet <[email-masked]>
Date: Tue, 31 Mar 1998 00:03:58 -0800

Yonadav:

Thanks for your reply. By MTU, I meant the maximum packet size allowable for
the media. On the sending host, the protocol stack will fragment the
application's buffers to the MTU size. So - if the MTU is larger then the
bucket size, and the packet scheduler resides below the fragmenting IP
stack, then many of the packets reaching the packet scheduler will be larger
than the bucket size (regardless of the max sdu size specified in the
flowspec). In this case, sending the packet will cause a burst to be placed
on the wire, which is greater than the bucket size. This is the problem.

It seems that regardless, "shape' mode is useful so that it can enforce the
token rate and the peak rate (which can still be enforced, even if the
bucket size is violated.

In your reply, you state that any node must be able to keep one packet per
RSVP flow until its that packet's turn to be transmitted. I read this to
mean that sin gle packets in excess of the burst (or bucket) size should be
tolerated, but that back to back packets will not. This is the general
impression I get from ohter replies I have received so far.

Thanks
Yoram

> -----Original Message-----
> From:	Yonadav Perry [SMTP:[email-masked]]
> Sent:	Monday, March 30, 1998 7:58 AM
> To:	Yoram Bernet
> Cc:	[email-masked]
> Subject:	Re: interpretation of bucket size in intserv flowspecs, by
> hosts
> 
> Yoram,
>