headers
Lisong Xu | 15 Mar 2011 23:36
Picon

Identifying TCP congestion control algorithms, and measurement results

Greetings,

We have recently developed a tool, called TCP Congestion Control
Avoidance Identification (CAAI), for actively identifying the TCP
congestion avoidance algorithm of a remote web server. We used CAAI to
measure the TCP algorithms of the top 5000 web sites in February 2011,
and got some preliminary results in which you might be interested.

# Only 16.85~25.58% of web servers still use the traditional AIMD.
# 14.36%, 15.82%, and 14.33% of web servers use BIC, CUBIC' (kernel
2.6.25 and before), and CUBIC (kernel 2.6.26 and after), respectively.
Total = 44.51%.
# 9.97% and 0.30~9.03% of web servers use CTCP' (Windows Server 2003
and XP Pro x64) and CTCP (Windows Server 2008, Vista, and 7),
respectively. Interestingly, CTCP' behaves very similar to HSTCP.
Total = 10.27~19%.
# Some web servers use non-default TCP algorithms (such as YEAH), some
web servers use some unknown TCP algorithms which are not available in
any major operating system family, and some web servers use abnormal
slow start algorithms.

More information is available at our project webpage
http://cse.unl.edu/~xu/research/TCPcensus.html.

Thanks
Lisong

--

-- 
Lisong Xu, Associate Professor
Computer Science & Engineering
(Continue reading)

Permalink | Reply | 0 comments |
headers
michawe | 21 Mar 2011 11:21
Picon
Picon

Looking for measurements on UDP blocking and rate limiting

Hi,

I just spent quite a long time searching, including digging through the last couple of years of IMC, PAM and
SIGMETRICS - but to my surprise, I was unable to find any measurement study on UDP blocking or UDP-specific
(as opposed to TCP-) rate limiting in the Internet. There must be some studies out there?!

Any hints would be greatly appreciated; and very sorry for the noise in case I just overlooked a very obvious
and well-known reference!
Michael
Permalink | Reply | 2 comments |
headers
Partha Kanuparthy | 22 Mar 2011 05:57
Picon
Favicon

Re: Looking for measurements on UDP blocking and rate limiting

Hi Michael,

This is in response to your question on UDP rate limiting. We have been 
working on a tool called ShaperProbe to detect traffic shaping 
signatures on UDP traffic, and to estimate the corresponding token 
bucket parameters. We host it as a service on M-Lab; please feel free to 
test it:
http://www.measurementlab.net/measurement-lab-tools#tool5

We have collected shaping data from several ISPs over the last couple of 
months. A tech report describing a few ISP observations is online:
http://www.cc.gatech.edu/~partha/shaperprobe-TR.pdf

Thanks,
Partha.

michawe wrote:
> Hi,
> 
> I just spent quite a long time searching, including digging through the last couple of years of IMC, PAM and
SIGMETRICS - but to my surprise, I was unable to find any measurement study on UDP blocking or UDP-specific
(as opposed to TCP-) rate limiting in the Internet. There must be some studies out there?!
> 
> Any hints would be greatly appreciated; and very sorry for the noise in case I just overlooked a very
obvious and well-known reference!
> Michael
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
michawe | 22 Mar 2011 13:38
Picon
Picon

Re: Looking for measurements on UDP blocking and rate limiting

Thanks a lot, that's interesting!

but I should have been clearer in what I need: the difference between the rate achievable by TCP and UDP. 
(i.e. I care about TCP vs. UDP, and I don't care about the actual method of rate limitation, shaping or policing).

>From your TR, it seems that I can get an idea by comparing figures 9 and 14, which roughly indicates that Cox
probably doesn't differentiate between UDP and TCP for shaping; but these two experiment types are
probably not correlated...

Anyway, thanks again for this!

Cheers,
Michael

On Mar 22, 2011, at 5:57 AM, Partha Kanuparthy wrote:

> Hi Michael,
> 
> This is in response to your question on UDP rate limiting. We have been working on a tool called ShaperProbe
to detect traffic shaping signatures on UDP traffic, and to estimate the corresponding token bucket
parameters. We host it as a service on M-Lab; please feel free to test it:
> http://www.measurementlab.net/measurement-lab-tools#tool5
> 
> We have collected shaping data from several ISPs over the last couple of months. A tech report describing a
few ISP observations is online:
> http://www.cc.gatech.edu/~partha/shaperprobe-TR.pdf
> 
> Thanks,
> Partha.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kacheong Poon | 24 Mar 2011 08:52
Picon
Favicon

TCP sequence number reset

Just want to get some opinion from the list members about an
idea proposed in an IETF draft.  The equivalent idea when
applied to TCP is sequence number reset.  The idea is that
assuming an application can access TCP sequence number with
each byte of data, an app is allowed to reset the TCP sequence
number when it wants to.  The sequence number is set to a number
not acceptable (add 231) in the current connection.  Note that
there is no clear usage proposed in that draft nor any reason
that it is needed, just a mechanism to do it.  I want to see
whether folks on this list think that it is a good or bad idea?
And why?

Thanks.

--

-- 

					K. Poon.
					ka-cheong.poon <at> oracle.com
Permalink | Reply | 30 comments |
headers
Eric Brown | 24 Mar 2011 14:38
Picon
Favicon

Re: TCP sequence number reset

Whether the idea proposed in the draft you are referencing truly
has an analogue in TCP may or may not be true. You haven't included
a reference. That being said, I'd consider this to be a bad thing with
respect to TCP. First and foremost TCP is a distributed state machine,
that is how it is able to achieve reliable and ordered delivery of
data in even the most hostile of conditions. A necessary component of
a distributed state machine is a virtual clock. Sequence numbers are
TCP's virtual clock ensuring that the FSM progresses in order. In the
very least it would be difficult to understand all the consequences of
overloading more semantics on the progression of the sequence space.

--Eric Brown, Virginia Tech

On Thu, Mar 24, 2011 at 03:52:15PM +0800, Kacheong Poon wrote:
> Just want to get some opinion from the list members about an
> idea proposed in an IETF draft.  The equivalent idea when
> applied to TCP is sequence number reset.  The idea is that
> assuming an application can access TCP sequence number with
> each byte of data, an app is allowed to reset the TCP sequence
> number when it wants to.  The sequence number is set to a number
> not acceptable (add 231) in the current connection.  Note that
> there is no clear usage proposed in that draft nor any reason
> that it is needed, just a mechanism to do it.  I want to see
> whether folks on this list think that it is a good or bad idea?
> And why?
>
> Thanks.
>
>
> --
(Continue reading)

Permalink | Reply | 27 comments |
headers
rick jones | 24 Mar 2011 15:22
Picon

Re: TCP sequence number reset


On Mar 24, 2011, at 12:52 AM, Kacheong Poon wrote:

> Just want to get some opinion from the list members about an
> idea proposed in an IETF draft.  The equivalent idea when
> applied to TCP is sequence number reset.  The idea is that
> assuming an application can access TCP sequence number with
> each byte of data, an app is allowed to reset the TCP sequence
> number when it wants to.  The sequence number is set to a number
> not acceptable (add 231) in the current connection.  Note that
> there is no clear usage proposed in that draft nor any reason
> that it is needed, just a mechanism to do it.  I want to see
> whether folks on this list think that it is a good or bad idea?
> And why?

The sequence number is a rather fundamental part of TCP's correctness  
mechanisms. For an application to futz with it, well, is just wrong.   
Particularly if there is no usage of/reason for its being presented.   
Too much rope.

rick jones

http://homepage.mac.com/perfgeek
Permalink | Reply | 0 comments |
headers
Kacheong Poon | 24 Mar 2011 17:48
Picon
Favicon

Re: TCP sequence number reset

On 03/24/11 09:38 PM, Eric Brown wrote:
> Whether the idea proposed in the draft you are referencing truly
> has an analogue in TCP may or may not be true. You haven't included
> a reference. That being said, I'd consider this to be a bad thing with
> respect to TCP. First and foremost TCP is a distributed state machine,
> that is how it is able to achieve reliable and ordered delivery of
> data in even the most hostile of conditions. A necessary component of
> a distributed state machine is a virtual clock. Sequence numbers are
> TCP's virtual clock ensuring that the FSM progresses in order. In the
> very least it would be difficult to understand all the consequences of
> overloading more semantics on the progression of the sequence space.

The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think
the analogy to TCP is accurate.

--

-- 

					K. Poon.
					ka-cheong.poon <at> oracle.com
Permalink | Reply | 26 comments |
headers
Stjepan Gros | 24 Mar 2011 21:45
Picon

Re: TCP sequence number reset

On Thu, 2011-03-24 at 15:52 +0800, Kacheong Poon wrote: 
> Just want to get some opinion from the list members about an
> idea proposed in an IETF draft.  The equivalent idea when
> applied to TCP is sequence number reset.  The idea is that
> assuming an application can access TCP sequence number with
> each byte of data, an app is allowed to reset the TCP sequence
> number when it wants to.  The sequence number is set to a number
> not acceptable (add 231) in the current connection.  Note that
> there is no clear usage proposed in that draft nor any reason
> that it is needed, just a mechanism to do it.  I want to see
> whether folks on this list think that it is a good or bad idea?
> And why?

I'll start with the question why should an application know/care about
sequence numbers of transport layer? No matter how hard I tried to think
of a reason for letting application know that I couldn't think of any.
If any application needs this functionality it can count those units for
itself (or prepend sequence numbers before sending data). Only
information currently unavailable to an application are sequence numbers
in flight, but again, of what use is that? In other words, sequence
numbers have certain meaning to the transport layer, and now this
mechanism would allow applications to add their own semantic on top of
it and make things even more complex. 

So let me try to summarize objections/comments valid for, at least, TCP:

A. There is no point in introducing any mechanism into any protocol
without a proper justification/motivation of what benefit it would
bring. Otherwise, it's only purpose is to increase protocol's complexity
(that of implemented protocol and/or in the number of protocol
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 24 Mar 2011 23:47
Picon
Favicon

Re: TCP sequence number reset


On 3/24/2011 9:48 AM, Kacheong Poon wrote:
> On 03/24/11 09:38 PM, Eric Brown wrote:
>> Whether the idea proposed in the draft you are referencing truly
>> has an analogue in TCP may or may not be true. You haven't included
>> a reference. That being said, I'd consider this to be a bad thing with
>> respect to TCP. First and foremost TCP is a distributed state machine,
>> that is how it is able to achieve reliable and ordered delivery of
>> data in even the most hostile of conditions. A necessary component of
>> a distributed state machine is a virtual clock. Sequence numbers are
>> TCP's virtual clock ensuring that the FSM progresses in order. In the
>> very least it would be difficult to understand all the consequences of
>> overloading more semantics on the progression of the sequence space.
>
>
> The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think
> the analogy to TCP is accurate.

SCTP includes the idea of individual streams, and the value of the 
sequence number has a meaning within a stream. In the above draft, it's 
used to allow a stream to be reused within an E2E association.

In TCP, the sequence number only has meaning to the reliability of the 
stream; there's only one E2E association. Resetting the number has no 
semantic value within the stream. There is no way to establish that TCP 
has no outstanding data, and so *can* reset the stream, other than via a 
FIN (which would close the connection).

Applications in TCP never see or know the sequence number. All they know 
is the byte stream they are presented with.
(Continue reading)

Permalink | Reply | 25 comments |

Gmane