Packet size s on CCID3

Packet size s on CCID3

[Ian McDonald]

I have been discussing the packet size s for CCID3 (TFRC) with my
supervisor and also been discussing related issues with Gerrit and I
am wondering why we have this?

CCID3 is datagram based and the whole point of s is to keep packets at
a certain rate per second. In effect provided s is calculated
correctly it cancels out of the equation but it becomes more
complicated in the code! If it is miscalculated (accidentally or
deliberately) it becomes worse because you are either starved or send
too much.

Why not just calculate a packet rate per second? Or am I missing
something obvious?

I'm looking to apply this in other areas of implementation as well -
for example packet buffering in TCP is traditional done with a limit
of bytes where DCCP would make more sense to limit this on number of
packets - and the code would be much easier too.

Calculating on packets per second also has the effect that it is
visible to application designers potentially who will put more data in
a datagram to increase throughput.

Comments?

Regards,

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [dccp] Packet size s on CCID3

[Gorry Fairhurst]

Let, me add a few more thoughts, and see what others think...

* I also have a problem with how to find "s" when thinking about an
"unknown" application. I'm not really sure how this is intended to work for
variable-sized packets. Calculating an average value for an application that
naturally varies the size doesn't seem to me to be straight-forward.

One value of "s" that makes sense, is possibly the largest segment size sent
by the session. This is at least conservative - for fixed-sized flows it is
identical to the optimum "s". For bursty flows, it is safe.

* The second part to your question seems to suggest a different method for
finding a safe transmission rate. That's something that has been interesting
us too, and is worthy of more thought.

Gorry 

On 21/9/06 04:22, "Ian McDonald" <ian.mcdonald@jandi.co.nz> wrote:

> I have been discussing the packet size s for CCID3 (TFRC) with my
> supervisor and also been discussing related issues with Gerrit and I
> am wondering why we have this?
> 
> CCID3 is datagram based and the whole point of s is to keep packets at
> a certain rate per second. In effect provided s is calculated
> correctly it cancels out of the equation but it becomes more
> complicated in the code! If it is miscalculated (accidentally or
> deliberately) it becomes worse because you are either starved or send
> too much.
> 
> Why not just calculate a packet rate per second? Or am I missing
> something obvious?
> 
> I'm looking to apply this in other areas of implementation as well -
> for example packet buffering in TCP is traditional done with a limit
> of bytes where DCCP would make more sense to limit this on number of
> packets - and the code would be much easier too.
> 
> Calculating on packets per second also has the effect that it is
> visible to application designers potentially who will put more data in
> a datagram to increase throughput.
> 
> Comments?
> 
> Regards,
> 
> Ian

Re: [dccp] Packet size s on CCID3

[Ian McDonald]

On 9/22/06, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> Let, me add a few more thoughts, and see what others think...
>
> * I also have a problem with how to find "s" when thinking about an
> "unknown" application. I'm not really sure how this is intended to work for
> variable-sized packets. Calculating an average value for an application that
> naturally varies the size doesn't seem to me to be straight-forward.
>
> One value of "s" that makes sense, is possibly the largest segment size sent
> by the session. This is at least conservative - for fixed-sized flows it is
> identical to the optimum "s". For bursty flows, it is safe.
>
It is actually the opposite of what you say here. If you do the maths
and set s large then you can send more packets per second than what
you should be able to.

-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [dccp] Packet size s on CCID3

[Sally Floyd]

> Why not just calculate a packet rate per second? Or am I missing
> something obvious?

No, that is a good question.

One reason for including the packet size s is discussed in
Section 5.3 of RFC 4342:

    "The packet size s is used in the TCP throughput equation.  A CCID 3
    implementation MAY calculate s as the segment size averaged over
    multiple round trip times -- for example, over the most recent four
    loss intervals, for loss intervals as defined in Section 6.1.
    Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
    to derive s.  In this case, s is set to the Maximum Segment Size
    (MSS), the maximum size in bytes for the data segment, not including
    the default DCCP and IP packet headers.  Each packet transmitted then
    counts as one MSS, regardless of the actual segment size, and the TCP
    throughput equation can be interpreted as specifying the sending rate
    in packets per second."

Thus, an implementation MAY calculate the allowed sending rate
in bytes per second, using for s the average segment size.
Or an implementation may use the MSS for s, and in fact calculate
the allowed sending rate simply in packets per second.  This would be
a purely local implementation decision.

- Sally
http://www.icir.org/floyd/

Re: Packet size s on CCID3

[Gerrit Renker]

Quoting Ian McDonald:
|  I have been discussing the packet size s for CCID3 (TFRC) with my
|  supervisor and also been discussing related issues with Gerrit and I
|  am wondering why we have this?
|  
|  CCID3 is datagram based and the whole point of s is to keep packets at
|  a certain rate per second. In effect provided s is calculated
|  correctly it cancels out of the equation but it becomes more
|  complicated in the code! If it is miscalculated (accidentally or
|  deliberately) it becomes worse because you are either starved or send
|  too much.
|  
|  Why not just calculate a packet rate per second? Or am I missing
|  something obvious?
I think this is confusing, as it mixes implementation issues with the theory.

Theory: 
-------
One cannot remove s since it is part of the underlying model. A good explanation
is in [3, chapter 2].  The throughput equation used for TFRC has the form
                  X  =  s/RTT *  f(loss_rate)
The `s' originates from the TCP throughput equations where it originally meant 
maximum segment size (see [1,2]), which relates to the previous two comments.

Practice:
---------
Both CCID 2 and CCID 3 are for fixed packet sizes (cf sections 5.3 of RFC 4341/2), 
i.e. s is a constant and hence you can indeed normalize the equation by dividing 
both sides of the equation by s.

The problem is that an application may be malicious and alter its sending packet
sizes, rfc3448bis suggests to average such changes out. With regard to the implemen-
tation, it may be good to use a weighted average of the form such as e.g.:
                  s  =  q * len + (1-q) * s
where `len' is either the buffer length at the sender or the size of an incoming
packet at the receiver. 

Gerrit


References:
-----------
[1]          Mathis, Matthew, Jeffrey Semke, Jamshid Mahdavi and Teunis Ott.
             The Macroscopic Behavior of the Congestion Avoidance Algorithm.
             ACM SIGCOMM Computer Communication Review, 27(3):67--82, 7/1997.

[2]          Padhye, J., V. Firoiu, D. Towsley and J. Kurose. Modeling TCP
             Throughput: A Simple Model and its Empirical Validation. ACM
             Computer Communication Review, 28(4):303--314, 1998.
[3]          Widmer, Jörg. Equation-Based Congestion Control. Diploma Thesis,
             University of Mannheim, Germany, 2/2000.

Re: [dccp] Packet size s on CCID3

[Eddie Kohler]

> It is actually the opposite of what you say here. If you do the maths
> and set s large then you can send more packets per second than what
> you should be able to.

While this is true, note that the draft explicitly allows implementations to 
use the maximum segment size (i.e. the largest value possible) for s!  So we 
are not THAT concerned about this kind of lying.

The bad case would be using one value of "s" to calculate "X", and then using 
a DIFFERENT value of "s" to calculate the packet rate from "X".  As long as 
the same value of "s" is used to calculate "X" and to calculate the packet 
rate from "X", the "s"s cancel out, as Ian points out.  For mostly-fixed-size 
applications, no problem; the network will provide whatever feedback is 
appropriate.

Why do we have "s" at all?  "s" helps account for applications that vary their 
packet size over the long term.  E.g., 20 RTT of packet size X, alternating 
with 20 RTT of packet size 3X.  We do not have simulations demonstrating what 
affect an incorrect "s" value would have in such a situation.  It would be 
interesting to see some data.

As Sally points out as well, the draft explicitly allows implementations to 
cancel out the "s" (by assuming s=MSS), calculating rates in packets per 
second only.

Eddie

Re: [dccp] Packet size s on CCID3

[Gorry Fairhurst]

Eddie Kohler wrote:

>> It is actually the opposite of what you say here. If you do the maths
>> and set s large then you can send more packets per second than what
>> you should be able to.
> 
> 
> While this is true, note that the draft explicitly allows 
> implementations to use the maximum segment size (i.e. the largest value 
> possible) for s!  So we are not THAT concerned about this kind of lying.
> 
> The bad case would be using one value of "s" to calculate "X", and then 
> using a DIFFERENT value of "s" to calculate the packet rate from "X".  
> As long as the same value of "s" is used to calculate "X" and to 
> calculate the packet rate from "X", the "s"s cancel out, as Ian points 
> out.  For mostly-fixed-size applications, no problem; the network will 
> provide whatever feedback is appropriate.
> 
> Why do we have "s" at all?  "s" helps account for applications that vary 
> their packet size over the long term.  E.g., 20 RTT of packet size X, 
> alternating with 20 RTT of packet size 3X.  We do not have simulations 
> demonstrating what affect an incorrect "s" value would have in such a 
> situation.  It would be interesting to see some data.
> 
> As Sally points out as well, the draft explicitly allows implementations 
> to cancel out the "s" (by assuming s=MSS), calculating rates in packets 
> per second only.
> 
> Eddie
> 
> 

That is consistent with my understanding.]

Thanks,

Gorry

P.S. I'm going through the TFRC-SP I-D in detail just now (with my WG 
Chair hat on).

Re: [dccp] Packet size s on CCID3

[Ian McDonald]

On 9/23/06, Sally Floyd <sallyfloyd@mac.com> wrote:
> > Why not just calculate a packet rate per second? Or am I missing
> > something obvious?
>
> No, that is a good question.
>
> One reason for including the packet size s is discussed in
> Section 5.3 of RFC 4342:
>
>     "The packet size s is used in the TCP throughput equation.  A CCID 3
>     implementation MAY calculate s as the segment size averaged over
>     multiple round trip times -- for example, over the most recent four
>     loss intervals, for loss intervals as defined in Section 6.1.
>     Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
>     to derive s.  In this case, s is set to the Maximum Segment Size
>     (MSS), the maximum size in bytes for the data segment, not including
>     the default DCCP and IP packet headers.  Each packet transmitted then
>     counts as one MSS, regardless of the actual segment size, and the TCP
>     throughput equation can be interpreted as specifying the sending rate
>     in packets per second."
>
> Thus, an implementation MAY calculate the allowed sending rate
> in bytes per second, using for s the average segment size.
> Or an implementation may use the MSS for s, and in fact calculate
> the allowed sending rate simply in packets per second.  This would be
> a purely local implementation decision.
>
> - Sally

I'm still thinking this all through and want to discuss this a bit further.

The papers by Padhye and Floyd for the TCP throughput equation all
seem to say that given a fixed RTT and fixed loss rate that you have a
fixed throughput rate in packets per second. Have I read this
correctly?

The throughput rate is then based on the packet size for a given loss
rate and RTT. If packet sizes increase, throughput increases but the
packet transmission rate remains the same.

Said another way we don't alter packet sending rate if we alter the
size of the packet. I'm not sure that this is correct on things like
wireless links but this is the starting point for TFRC at present.

If the mss is used then t_ipi = s/X_inst according to TFRC spec. That
means that it will get less than fair share which makes sense (Richard
I had this around the wrong way when we were discussing).

I personally don't see why you would do all the calculations for
average packet size etc when you can simplify it by just counting
packets. I'm guessing that it was done in this way because people
wanted to calculate throughput rates due to the protocols being
thought of but this is far less relevant when you are datagram based
and don't normally fragment.

If I get time I'll experiment with implementations in Linux.

Regards,

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [dccp] Packet size s on CCID3

[Ian McDonald]

Just re-reading this again:

> One reason for including the packet size s is discussed in
> Section 5.3 of RFC 4342:
>
>     "The packet size s is used in the TCP throughput equation.  A CCID 3
>     implementation MAY calculate s as the segment size averaged over
>     multiple round trip times -- for example, over the most recent four
>     loss intervals, for loss intervals as defined in Section 6.1.
>     Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
>     to derive s.  In this case, s is set to the Maximum Segment Size
>     (MSS), the maximum size in bytes for the data segment, not including
>     the default DCCP and IP packet headers.  Each packet transmitted then
>     counts as one MSS, regardless of the actual segment size, and the TCP
>     throughput equation can be interpreted as specifying the sending rate
>     in packets per second."
>
> Thus, an implementation MAY calculate the allowed sending rate
> in bytes per second, using for s the average segment size.
> Or an implementation may use the MSS for s, and in fact calculate
> the allowed sending rate simply in packets per second.  This would be
> a purely local implementation decision.
>
> - Sally

Why do we have to assume s = MSS? If we actually track the number of
packets this makes the situation far worse and we can't send at a fair
rate. For example if MSS is 1500 bytes and we are actually using 50
byte packets then we can only send 1/30 th of what we are permitted
under the TCP throughput equation.

Using MSS is fair if we are using a byte rate per second
implementation but if we do a packet per second implementation (given
X and s act to cancel out) this seems patently wrong.

This would not be open to application abuse as the protocl would be
just tracking packets per second.

Forgive me if I'm making a fundamental error - I would like to see
what I am doing wrong if I am. I know that what I am saying is not
what RFC4342 says but I'm referring to the ideas behind it.

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [dccp] Packet size s on CCID3

[Eddie Kohler]

There are a couple issues with the packet size.

This mail will list my understanding of those issues.  It has no solutions, 
for that there will be another mail.

One thing we have had to consider is that different congestion points in the 
network might have different limitations.  Conventional wisdom is that 
congestion points, such as router output queues, are essentially limited in 
bytes.  That is, a packet of length 200 occupies 200 units of the bottleneck 
resource, where a packet of length 40 occupies 40 units only.  However, in the 
past and probably in the future, some congestion points have been limited in 
PACKETS.  Thus, packets of length 200 and 40 occupy THE SAME AMOUNT of 
bottleneck resource.  And there are other possibilities.

If we were guaranteed that all bottlenecks in the Internet were limited in 
packets, we could stop worrying about the packet size s.  All flows sending K 
packets/sec would observe the same loss rate, regardless of their packet 
sizes.  So a packet-based loss response would react to all congestion 
appropriately.

However that is not the real world.  In the real world a flow sending K small 
packets/sec may occupy LESS bottleneck resource than a flow sending K LARGE 
packets/sec.

So what? you may ask.  If the small-packet flow is occupying less bottleneck 
resource, perhaps it will observe a lower loss event rate than a large-packet 
flow, and thus still occupy its fair share.  The answer is that it MIGHT 
observe a lower loss event rate and it might not.

Also, there is the problem of dynamics.  If a flow sends small packets for 5 
years and then shifts to Gigantapackets (tm), the packet/sec loss rate 
observed over the last 5 years is probably not a fair metric for the 
Gigantapacket transmission rate in packets/sec.  In the long term, of course, 
the Gigantapacket flow will observe its correct loss rate and settle down to a 
fair rate, but the short term could get ugly.  And then what about flows whose 
dynamics shift wildly??

Eddie



Ian McDonald wrote:
> On 9/23/06, Sally Floyd <sallyfloyd@mac.com> wrote:
>> > Why not just calculate a packet rate per second? Or am I missing
>> > something obvious?
>>
>> No, that is a good question.
>>
>> One reason for including the packet size s is discussed in
>> Section 5.3 of RFC 4342:
>>
>>     "The packet size s is used in the TCP throughput equation.  A CCID 3
>>     implementation MAY calculate s as the segment size averaged over
>>     multiple round trip times -- for example, over the most recent four
>>     loss intervals, for loss intervals as defined in Section 6.1.
>>     Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
>>     to derive s.  In this case, s is set to the Maximum Segment Size
>>     (MSS), the maximum size in bytes for the data segment, not including
>>     the default DCCP and IP packet headers.  Each packet transmitted then
>>     counts as one MSS, regardless of the actual segment size, and the TCP
>>     throughput equation can be interpreted as specifying the sending rate
>>     in packets per second."
>>
>> Thus, an implementation MAY calculate the allowed sending rate
>> in bytes per second, using for s the average segment size.
>> Or an implementation may use the MSS for s, and in fact calculate
>> the allowed sending rate simply in packets per second.  This would be
>> a purely local implementation decision.
>>
>> - Sally
> 
> I'm still thinking this all through and want to discuss this a bit further.
> 
> The papers by Padhye and Floyd for the TCP throughput equation all
> seem to say that given a fixed RTT and fixed loss rate that you have a
> fixed throughput rate in packets per second. Have I read this
> correctly?
> 
> The throughput rate is then based on the packet size for a given loss
> rate and RTT. If packet sizes increase, throughput increases but the
> packet transmission rate remains the same.
> 
> Said another way we don't alter packet sending rate if we alter the
> size of the packet. I'm not sure that this is correct on things like
> wireless links but this is the starting point for TFRC at present.
> 
> If the mss is used then t_ipi = s/X_inst according to TFRC spec. That
> means that it will get less than fair share which makes sense (Richard
> I had this around the wrong way when we were discussing).
> 
> I personally don't see why you would do all the calculations for
> average packet size etc when you can simplify it by just counting
> packets. I'm guessing that it was done in this way because people
> wanted to calculate throughput rates due to the protocols being
> thought of but this is far less relevant when you are datagram based
> and don't normally fragment.
> 
> If I get time I'll experiment with implementations in Linux.
> 
> Regards,
> 
> Ian

Re: [dccp] Packet size s on CCID3

[Eddie Kohler]

The answer of course is that you DON'T have to assume that s=MSS here, you can 
use the real packet size.  So am I missing something in your question?

If s cancels out (bc you are designing a packets/sec implementation), then it 
doesn't matter what s is.  Set it to MSS, set it to 1, who cares?  The 
packet/sec rate you get out of the throughput equation will be the same, no?

Eddie


Ian McDonald wrote:
> Just re-reading this again:
> 
>> One reason for including the packet size s is discussed in
>> Section 5.3 of RFC 4342:
>>
>>     "The packet size s is used in the TCP throughput equation.  A CCID 3
>>     implementation MAY calculate s as the segment size averaged over
>>     multiple round trip times -- for example, over the most recent four
>>     loss intervals, for loss intervals as defined in Section 6.1.
>>     Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
>>     to derive s.  In this case, s is set to the Maximum Segment Size
>>     (MSS), the maximum size in bytes for the data segment, not including
>>     the default DCCP and IP packet headers.  Each packet transmitted then
>>     counts as one MSS, regardless of the actual segment size, and the TCP
>>     throughput equation can be interpreted as specifying the sending rate
>>     in packets per second."
>>
>> Thus, an implementation MAY calculate the allowed sending rate
>> in bytes per second, using for s the average segment size.
>> Or an implementation may use the MSS for s, and in fact calculate
>> the allowed sending rate simply in packets per second.  This would be
>> a purely local implementation decision.
>>
>> - Sally
> 
> Why do we have to assume s = MSS? If we actually track the number of
> packets this makes the situation far worse and we can't send at a fair
> rate. For example if MSS is 1500 bytes and we are actually using 50
> byte packets then we can only send 1/30 th of what we are permitted
> under the TCP throughput equation.
> 
> Using MSS is fair if we are using a byte rate per second
> implementation but if we do a packet per second implementation (given
> X and s act to cancel out) this seems patently wrong.
> 
> This would not be open to application abuse as the protocl would be
> just tracking packets per second.
> 
> Forgive me if I'm making a fundamental error - I would like to see
> what I am doing wrong if I am. I know that what I am saying is not
> what RFC4342 says but I'm referring to the ideas behind it.
> 
> Ian

Re: [dccp] Packet size s on CCID3

[Ian McDonald]

On 10/4/06, Eddie Kohler <kohler@cs.ucla.edu> wrote:
> The answer of course is that you DON'T have to assume that s=MSS here, you can
> use the real packet size.  So am I missing something in your question?

Yes. See below.
>
> If s cancels out (bc you are designing a packets/sec implementation), then it
> doesn't matter what s is.  Set it to MSS, set it to 1, who cares?  The
> packet/sec rate you get out of the throughput equation will be the same, no?
>
As I read RFC4342 I can't implement a packets per second
implementation directly - there are several options but packets per
second is not one of them. The mathematical equation allows it as you
seem to agree by your first statement. The RFC doesn't. If we track
the average packet size it works but then that is a whole lot more
complex code to achieve exactly the same thing.

> Eddie

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [dccp] Packet size s on CCID3

[Eddie Kohler]

> As I read RFC4342 I can't implement a packets per second
> implementation directly - there are several options but packets per
> second is not one of them. The mathematical equation allows it as you
> seem to agree by your first statement. The RFC doesn't. If we track
> the average packet size it works but then that is a whole lot more
> complex code to achieve exactly the same thing.

I disagree with this reading of the RFC.  The RFC explicitly allows the sender 
to calculate X as if every packet had size 's = MSS'.  As usual, the 
implementation can then implement any simplifications such an assumption would 
allow.  An implementation that assumes 's = MSS' can therefore calculate a 
sending rate in packets per second.

Eddie

Re: [dccp] Packet size s on CCID3

[Ian McDonald]

> I disagree with this reading of the RFC.  The RFC explicitly allows the sender
> to calculate X as if every packet had size 's = MSS'.  As usual, the
> implementation can then implement any simplifications such an assumption would
> allow.  An implementation that assumes 's = MSS' can therefore calculate a
> sending rate in packets per second.
>
> Eddie
>
OK. Time for some maths with the TCP throughput equation. I am using
an online version here backed up with testing with my modified DCCP
stack - this matches on runs to within 10% of this equation. The
online equation is here - http://wand.net.nz/~perry/max_download.php -
in the examples below I have changed rtt to 250 ms and loss to 5 %.

In this online calculator the value for s is put into MSS. The reason
for this is we are assuming we are sending maximum size packets which
may not be applicable for DCCP but is for TCP. So we vary the MSS to
reflect s here.

Now starting with a s of 1460 bytes we get a throughput (Xcalc) of
15221 bytes/sec. Now t_ipi is s/X_inst and X_inst on average is X_calc
(it is just adjusted to prevent oscillation). So t_ipi is 96 msecs.

Now change s to 300 bytes we get a Xcalc of 3128 and a t_ipi of 96
msecs. Put in ANY number for s and you will get the same t_ipi of 96
msecs.

This illustrates my point that CCID3 is a packet per second based
congestion control.

Now if we specify the s is 300 to the implementation we get the
desired result, if we average it we get the correct result. However we
can't switch to a packet based equation because if we do the spec says
we should use s=MSS. Lets assume MSS\x1460. Now Xcalc is 15221
bytes/sec. t_ipi is 96 msecs. And we can send the correct rate of
packets.

OK Now working through the example shows that my logic was wrong. I
guess thats what defence of ideas is about - proving it and my idea
was wrong. I apologise for wasting everybody's time!

However this does show an application can't cheat by specifying the
wrong packet size which the spec worries about. Maybe my working
through this helps resolve this a little...

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [dccp] Packet size s on CCID3

[Eddie Kohler]

Hi Ian,

Ian McDonald wrote:
> Now change s to 300 bytes we get a Xcalc of 3128 and a t_ipi of 96
> msecs. Put in ANY number for s and you will get the same t_ipi of 96
> msecs.
> 
> This illustrates my point that CCID3 is a packet per second based
> congestion control.
> 
> Now if we specify the s is 300 to the implementation we get the
> desired result, if we average it we get the correct result. However we
> can't switch to a packet based equation because if we do the spec says
> we should use s=MSS. Lets assume MSS\x1460. Now Xcalc is 15221
> bytes/sec. t_ipi is 96 msecs. And we can send the correct rate of
> packets.

You absolutely CAN switch to a packet based equation (assuming s is fixed at 
MSS), because that packet based equation will have ENTIRELY IDENTICAL BEHAVIOR 
to the byte based equation!  Specs talk about observed behavior, that is what 
makes them specs.


> OK Now working through the example shows that my logic was wrong. I
> guess thats what defence of ideas is about - proving it and my idea
> was wrong. I apologise for wasting everybody's time!
> 
> However this does show an application can't cheat by specifying the
> wrong packet size which the spec worries about. Maybe my working
> through this helps resolve this a little...

This is not quite right.  Applications might be able to cause *transient* 
unfairness (in a purely packet-based implementation) by switching to a larger 
packet size after sending small packets for a while.  The unfairness is only 
transient because, if the app keeps sending large packets, eventually the loss 
event rate will catch up with the app's current behavior.

Personally, I do not believe this transient unfairness is a critical issue. 
Preliminary simulations showed apps didn't gain in the long run from doing 
this.  None of the current discussion has changed my mind.  Some real 
experiments could.

Eddie