[e2e] TCP Spoofing and Path Tail Emulation

[Detlef Bosau]

Hi to all!

I´m just reading Mark Allman´s paper "On the Performance of TCP Spoofing 
in Sattellite Networks" and have some questions.

I explicitly say _questions_. As usual, it´s a large stack of paper to 
read and perhaps I missed some details.

However, this work directly relates to my own Path Tail Emulation (PTE) 
approach and therefore I´m interested in this discussion.

Perhaps, it may be somewhat suprising that I talked about PTE in the 
context of loss differentiation during the last days and now talk about 
satellite communication. In fact, that list is easily extended because 
some issues are basically the same.

So, let´s start here with Martin´s post.

However, for those of you who are not familiar with Path Tail Emulation 
(presumably most of you because I only published it on a German 
conference and now, I´m struggling with the CiteSeer for a few months to 
have it listed) I will give a reference here:

@inproceedings{bosau,
booktitle = "KiVS Kurzbeiträge und Workshop 2005",
year = 2005,
title = "{Path Tail Emulation: An Approach to Enable End--to--End
           Congestion Control for Split Connections and Performance
           Enhancing Proxies}",
author =  "D.~Bosau",
address = "Kaiserslautern, Germany",
pages = "33-40"
}

http://www.detlef-bosau.de/043.pdf


> 
> [e2e] TCP spoofing in overlay networks
> Martin Swany swany at cis.udel.edu
> Wed Mar 2 10:45:16 PST 2005
> 
>     * Previous message: [e2e] TCP spoofing in overlay networks
>     * Next message: [e2e] TCP spoofing in overlay networks
>     * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 
> Hi there,
> 
>> I recently had occaision to read a few papers about the practice of 
>> "TCP spoofing" over satellite links---i.e inserting a proxy prior to 
>> the satellite link to provide TCP feedback to the sender, effectively 
>> splitting into two TCP sessions connected in tandem. I was wondering 
>> if anyone had ever proposed a similar idea to improve TCP throughput 
>> in overlay networks over terestrial links.
> 
> We proposed such an approach in terms of an E2E "session" layer.  The 
> 2001
> tech report (and some newer information) is available here:
> http://www.cis.udel.edu/~swany/projects/lsl
> 
> regards,
> martin
> 


The interesting observation is that TCP spoofing is used in the context of
- grid computing (Martin Swany´s paper),
- satellite networking (Mark Allman´s paper),
- wireless Internet access (I-TCP by Bake, Badrinath, M-TCP by Brown, 
Singh).....

The pros and cons of each application are beyond the scope of this mail.

In each case, TCP spoofing / using a PEP (both terms are used as 
synonyms) aims to hide the properties of a network _Path_ _Tail_ behind 
a PEP.

E.g., in the particular case discussed by Mark Allman, it´s the 
transport latency introduced in a network path by a satellite link.
Figure 1 in his paper illustrates the main effect of spoofing: The 
perceived RTT for the sender is shortened.

However, I did not yet see how appropriate _rate_ control is achieved, 
i.e. the sender is made to send with a rate appropriate for the path. I 
presume, this is done using TCP flow control, as it is done in I-TCP. 
But please correct me if I´m wrong.

Sections 3.1.1 and 3.1.2 in RFC 3135 are rather general here.

Section 3.1.1 is quite related to what I suggest in my paper.

However, it´s not my intention to smoothen out the effect of packet 
burst, but to make the path tail appear as a single, loss free segment, 
the bandwidth and capacity of which refer to the emulated path tail.

In the particular case of a mobile wireless path tail, this is done 
using a smoothed estimate of the wireless paths actual throughput. (I´m 
currently working at the problem, how much smoothing I need.)

However, the mechanism is not restricted to mobile networks but can be 
applied to any arbitrary PEP. E.g. in Mark Allman´s scenario, a 
throughput estimate could be gained from Padhye´s forumal in conjunction 
with the LEAST algorithm.

As a perhaps somewhat extreme case, the path tail need not even be 
packet switched. Think of the Remote Socket Architecture (ReSoA) 
proposed by Schl"ager, Wolisz et al. ReSoA does not make any assumptions 
concerning the network technology behind the PEP.

I suggest PTE as an extension to PEP, which is easily adapted to 
different network scenarios by providing an appropriate throughput 
estimate.

And I would greatly appreciate some comments on this work. I think it is 
useful to discuss this mechanism, and PEP as well, in a rather general 
context, because the application of PEP / TCP spoofing is no way 
restricted to wireless networks. And the ongoing discussion on this 
matter makes clear, that there is an interest in PEP.

For the end-to-end argument, which is often risen in this context, I 
refer to section 4 in RFC 3135. This is a discussion particular to the 
PEP in use. For the "trivial PEP" used as an example in my work, I 
basically follow the rationale given by Chakravorthy et al., please find 
the reference in my paper.

DB



-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937