Subject: RE: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues

From: "Stephen Suryaputra" <[email-masked]>
Date: Mon, 8 Mar 2004 12:42:21 -0500

I think Marko is referring to the situation when there is a congestion.
Because of that the queue builds up and if the queue space is in term
of the number of packets, then a bunch of small packets can potentially
dominate the queue and left little room for large packets eventhough
there is a space in the buffer to accomodate the large ones.

Unless if there is anything I miss.

Cheers,

-----Original Message-----
From: Craig Partridge [mailto:[email-masked]]
Sent: Monday, March 08, 2004 11:15 AM
To: Marko Zec
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related
issues 

In message <[email-masked]>, Marko Zec writes:

>On Sunday 07 March 2004 23:06, Alexandre L. Grojsgold wrote:

>> Small packets get more buffer frames, but are also more rapidly sent.
>> The gueue grows fats, but shrinks fast too. It means that a burst of
>> small packets will not increase the packet loss, no mather the length
>> of the buffer (in packets).
>
>
>This theory is unfortunately wrong, because it ignores the fact that 
>when congestions do occur, traffic flows consisting of small packets 
>(regardless whether they are bursty or smooth) will use more buffer 
>slots then the flows carrying the larger ones, leaving less remaining 
>buffer slots available for queuing further packets / bursts.

I must be missing something here.  I think Alexandre's generally right.
If the buffers load and empty according to the amount of data in them,
then packet size isn't an issue.

The only situations in which this isn't true, that I can think off the
top of my head, are:

    * If the router has places where it moves all the bytes in the packet
      buffer, regardless of how much data the buffer actually contains.
      Since this would cause extraordinary internal bandwidth challenges,
      I doubt anyone does it for any but the lowest speed routers.

    * If the router has a deep pipeline and the time at each stage in the
      pipeline is set to equal the average packet time rather than the
      minimum packet time.  But most folks carefully design router pipelines
      for minimum packet times precisely because of this risk.

So clue me in -- what detail of router design am I missing?

Craig

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Marko Zec <[email-masked]>
Date: Tue, 9 Mar 2004 01:31:10 +0100

On Tuesday 09 March 2004 01:07, Craig Partridge wrote:
> In message <[email-masked]>, Marko Zec writes:
> >All I was trying to point out in my prior posts is that precisely in
> >such a situation bursty traffic will present a big failure.
>
> Right, but bursts only matter if they cause a queue to build up in a
> router. Putting a burst on a wire doesn't mean a queue in the router
> -- it depends on the speed of the routers inputs and outputs.
>
> Putting this another way, TCP causes a queue in the bottleneck router
> (the spot where A > D).

OK, can we then agree that making such a spot a subject to an additional 
traffic burst can be considered a bad thing?

Marko

---

From: Marko Zec <[email-masked]>
Date: Tue, 9 Mar 2004 00:46:30 +0100

On Monday 08 March 2004 22:50, Craig Partridge wrote:
> In message
> <[email-masked]>, "S
>
> tephen Suryaputra" writes:
> >I think Marko is referring to the situation when there is a
> > congestion. Because of that the queue builds up and if the queue
> > space is in term of the number of packets, then a bunch of small
> > packets can potentially dominate the queue and left little room for
> > large packets eventhough there is a space in the buffer to
> > accomodate the large ones.
>
> Well, I tried to nail this down by setting it up as a queueing system
> but that's awfully hard.  Here's the cut:
>
> 1. Basically you have a general arrival process delivering pieces of
> work of variable size, at arrival rate A subject to the condition
> that if there's an event of size w1 at time t1, then the next event
> cannot arrive sooner than time t1+w1.  [I.e. A(t2,w2) - A(t1,w1) >=
> w1].
>
> 2. You then have a series of queues Q1-Qn attached to servers S1-Sn
> that serve events at a fixed rate R, where R1 <= A (i.e. we can
> handle the maximum rate).
>
> 3.  You then have a departure queue D1, and departure server DS,
> which has a service rate D, where D can be defined such that D(w) <=
> w (that is, the output is faster or equivalent speed to the input) or
> D(w) >= w (output is slower).
>
>
> If D(w) <= w, then I think one can argue simply by inspection that
> the total work unit buffering in the system is [max(w)/min(w)]-n. 
> That is you simply need enough queueing to handle a queue that
> develops because a big packet causes a bunch of little packets to
> queue behind it (because they arrive while the big packet is going
> out).  See Comment (**) below.
>
> I can't find an easy solution for D(w) >= w, because, in general, the
> queue can grow without bound.

Isn't the TCP's ultimate performance goal precisely the maintenance of 
the equilibrium D(w) = w in the bottleneck queue? If you are a lucky 
owner of just the TCP implementation that has no problem of achieving 
that goal for the particular network configuration, the queue length on 
the bottleneck link will fluctuate - sometimes it will be almost empty, 
sometimes almost full, and every now and then it will even have to drop 
a packet or two, but hopefully not more than that.

All I was trying to point out in my prior posts is that precisely in 
such a situation bursty traffic will present a big failure. If the 
burst arrives when the buffer is almost full, then the majority of the 
packets from the burst will be discarded. Furthermore, if packets of 
smaller size are used, requiring more packets to carry the same amount 
of useful payload, the greater will be the percentage of such packets 
to be dropped, assuming the buffer size on the router is defined by the 
number of packets it can hold, regardless of packet size.

Marko

>
> ** If you believe this model, what it says is that if you go with
> packet size buffers, and the ratio between the smallest possible
> packet and largest possible packet is big, then you can find your
> queues growing quite large, due not to classic congestion (where
> there is too much demand fighting for one output link) but rather to
> serialization delays.
>
> Craig

---

From: Craig Partridge <[email-masked]>
Date: Mon, 08 Mar 2004 16:50:43 -0500

In message <[email-masked]>, "S

1. Basically you have a general arrival process delivering pieces of work
    of variable size, at arrival rate A subject to the condition that
    if there's an event of size w1 at time t1, then the next event cannot
    arrive sooner than time t1+w1.  [I.e. A(t2,w2) - A(t1,w1) >= w1].

2. You then have a series of queues Q1-Qn attached to servers S1-Sn that
    serve events at a fixed rate R, where R1 <= A (i.e. we can handle
    the maximum rate).

3.  You then have a departure queue D1, and departure server DS, which has
    a service rate D, where D can be defined such that D(w) <= w (that is,
    the output is faster or equivalent speed to the input) or D(w) >= w
    (output is slower).

If D(w) <= w, then I think one can argue simply by inspection that the total
work unit buffering in the system is [max(w)/min(w)]-n.  That is you
simply need enough queueing to handle a queue that develops because a big
packet causes a bunch of little packets to queue behind it (because they
arrive while the big packet is going out).  See Comment (**) below.

I can't find an easy solution for D(w) >= w, because, in general, the queue
can grow without bound.

** If you believe this model, what it says is that if you go with packet
size buffers, and the ratio between the smallest possible packet and
largest possible packet is big, then you can find your queues growing quite
large, due not to classic congestion (where there is too much demand
fighting for one output link) but rather to serialization delays.

Craig

---

From: Craig Partridge <[email-masked]>
Date: Mon, 08 Mar 2004 19:07:32 -0500

In message <[email-masked]>, Marko Zec writes:

>the equilibrium D(w) = w in the bottleneck queue?

No, TCP's goal is to equal the lesser of A or D (whatever they are).

>such a situation bursty traffic will present a big failure.

Right, but bursts only matter if they cause a queue to build up in a router.
Putting a burst on a wire doesn't mean a queue in the router -- it depends
on the speed of the routers inputs and outputs.

Putting this another way, TCP causes a queue in the bottleneck router (the
spot where A > D).

Craig