Subject: Re: [dtn-interest] updated version of TCP Planet
From: Howard Weiss <[email-masked]>
To: Ozgur Baris Akan <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 27 Jun 2003 13:22:36 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Comments in-line and below.

Ozgur Baris Akan wrote:

>>Joe Touch wrote:
>>
>>
>>    
>>
>>>Scott Burleigh wrote:
>>>      
>>>
>>...
>>    
>>
>>>Again, I'm no TCP expert, but it seems to me that the way TCP-Planet
>>>gets around the problems inherent in connection establishment (the
>>>Initial State algorithms) is pretty ingenious.
>>>      
>>>
>>FWIW, it doesn't appear that the Intial State alg gets around
>>connection
>> establishment, but rather focuses on the rapid initialization of the
>>congestion window. You still need a three-way handshake, with it's
>>RTTs.
>>    
>>
>
>
>The objective of the Initial State is to increase the transmission rate
>quickly in a controlled manner. However, TCP-Planet does also get around
>the connection establishment problem. The conventional TCP protocols
>perform three-way handshake and wait for the connection request ACK (SYN
>ACK). This wastes at least 1 RTT period, which is quite long in the IPN
>environment. However, TCP-Planet directly starts transmitting along with
>the connection request packet without waiting for the completion of the
>three-way handshake. If the connection request ACK is not received, or
>the connection is declined then the source also stops transmitting.
>Otherwise, it continues the connection (Please see Section II-D page 6)
>
>
>  
>
>>A similar technique to sending nil packets (FEC-style replicated data)
>>is to send real data, just at 'zero' priority during the beginning of
>>the window, as per:
>>
>>http://www.cis.upenn.edu/~dsl/read_reports/hkim_phd.ps.Z
>>Hyogon Kim. A Non-Feedback Congestion Control Framework for High-Speed
>>Data Networks. UPenn PhD Thesis, 1995.
>>
>>The primary difference is whether the duplicates help; in Kim's,
>>they're
>> productive. In TCP-Planet, they open the window presuming the
>>receiver
>>knows what to do with them AND that the sender knows what to do with
>>the
>> dup ACKs.
>>    
>>
>
>
>At the beginning of the connection, it would not be good idea to probe
>the link with the packets carrying new (unsent) data. Because, at the
>beginning the source does not have any information about the link at all
>these packets are primarily transmitted for probing purposes. Therefore,
>losing the NIL packets carrying sent but unacknowledged data is not a
>problem. However, if you lose your probe packet which contains new data,
>you have to deal with retransmission for reliability purposes.
>Furthermore, in the space links with very high delay, this problem
>becomes worse since it is possible to lose many of those "new data
>carrying" probe packets.
>

But isn't this just what you are doing by sending data without the 3-way 
handshake connection establishment?  Youare sending data w/o an 
established connection which is equivalent to probing with new data.  On 
page 6 you state: "If the request is rejected, then the connection is 
terminated after one RTT."   The paper claims that waiting for a 3-way 
handshake "results in waste of huge bandwidth for at least a duration of 
one RTT in deep space links."  By this you mean that the bandwidth is 
NOT used - I would look at bandwidth being wasted from another view - 
that you sent data w/o a fully established connection which potentially 
falls into the bit bucket is a waste of the bandwidth because it 
consumed bandwidth that is precious and may have been used by some other 
connection.

>>However, how does the other end know these are useful information, vs.
>>indications of lost ACKs? How does the source know that it should use
>>these dup acks to open its window? Current TCP won't do anything with
>>an
>> ACK unless it ACKs new data, unless it gets a few in a row, which
>>might throw it into fast retransmit or worse (close the window). It's
>>not
>>clear from the paper which is happening...
>>
>>    
>>
>
>
>In TCP-Planet, NIL packets are only sent in the Immediate Start of the
>Initial State algorithm (i.e., only first RTT of the connection period).
>The received NIL packets are not individually ACKed back by the
>receiver. This is prefered to avoid high traffic on the reverse channel.
>Any received NIL packet at the receiver reveals that much additional
>available capacity. The receiver counts the number of NIL packets it
>received in a time interval T (plus the data packets it received) and it
>only sends this information (the total number of packets it received in
>T) within NIL ACK. So, when the source receives this information, the
>source increases its data rate during Follow-Up phase by using this
>information (please see Section II where these are all explained).
>Therefore, if any NIL packet is not received (missing in a row), the
>receiver does not take any action.
>
>
>  
>
>>I agree with Scott that the connection appears inherently
>>conversational.
>>
>>Joe
>>    
>>
>
>  
>
I too agree that the connection is chatty with all of the NIL and NIX packets being sent and received.  

On the question of NIL and NIX, you state that these are sent using "low priority" using the IP TOS.  However, IP TOS does not have a notion of "low priority" datagrams - either they are "normal" or they are "high(er)" priority.  Does this mean that NIL/NIX are sent with normal TOS and that all normal traffic is sent as "high" priority?

On page 5 you talk about "scarce reverse channel resources."  I am confused about this given the architecture setting.  It appears that TCP-Planet is designed to operate over a long-delay "back-bone" between planets.  This architecture makes the long haul link look like a long-delay wire and its not clear which is the forward or the reverse channel.  And in fact, from the paper, it would appear that you think that the reverse channel is bandwidth limited (page 5).  Typically, the forward channel is from Earth to space and is bandwidth limited.  The reverse channel is the one from space to Earth and is usually the higher bandwidth channel (in order to bring down collected data).

It was not clear (at least to me) how black-out worked.  Its not clear how long to wait before entering black-out?  And then rather than shutdown and save power, NIX packets are sent - sort of analogous to zero window probes in TCP.

Howie Weiss

---------------------------
                                                                    
Howard Weiss      
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)