Transport protocols and bulk file transfer

["Injong Rhee" <>]

Hi Stas,

 

I have some comments on the document. Since I am coming from loss-based protocols, my comments could be a little biased. So please take it with some grains of salt. Hre is a quick brain-dump.

 

First, the document seems to weigh more in on delay-based protocols. I feel we need more discussion on which ways to go before we finally settle on the goals.

 

In Section 2.1 it is implied that loss-based protocols always double the delay and the currently deployed routers have RTT worth of buffers. In fact, the router buffers (from what I gather) are not as large as RTT. Typically, I hear that it is around 20% of the long RTT. STCP paper mentions about the lack of buffers and there were several references that comment on small buffers. Also router buffers are shared memory among several interfaces and ports. So per port memory could be limited. We need more data supporting your claims.

 

In the end of 2.1, you mentioned about tolerance to the losses. Are you referring to short-term throughput or long-term throughput? As you refer to response function, I assume that it is to long-term throughput. If non-congested losses are rare, it is not necessarily a characteristic of loss-based protocols that their tolerance to loss is very low. Consider TFRC. TFRC responds to the average loss rates – instead of instantaneous loss rates. Depending on the design, we can avoid congestion control to respond less sensitively to “rare” non-congestive losses.

 

In Section 2.3, references to SABUL and SOBAS. Could the authors of this protocol comment on the TCP friendliness of the protocols? Since we have the authors of SABUL on board, we can hear from the experts; but our experience with SABUL (old version) is that the protocol is not so stable and not designed for TCP-friendliness. But we could be wrong and also the protocol also could have been changed over time.

 

In Section 6, I think we need more clear definition on “under congestion”. Does this mean when you get congestion indication (i.e., queuing delays or losses)? Also I guess that the wording on loss-based protocols behaving exactly as TCP under congestion is not necessarily true. Also in general TCP-compatibility means that it can “co-exist” with TCP (not necessarily TCP-friendly). More precise definition of TCP friendliness can be found in Vojnovic’s paper (SIGCOMM 2003) where the competing flows use always less or equal bw than TCP flows. So from the context, you really want TCP-compatibility, but not TCP-friendliness. Some folks use TCP-friendliness more liberally as in this document. But when we compare both TCP compatibility and TCP friendliness, I guess there could be a different opinion.

 

Sorry about posting this so late. I was away for a conference last week and I just found time to read the document..

 

Injong