[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[Joe Touch]

Detlef Bosau wrote:
> Joe Touch wrote:
>>>
>>> First.
>>>
>>> The only scenrios where I see a justification / necessity for doing
>>> splitting or spoofing are scenarios where the TCP flow must pass the
>>> split box / spoofing box / PEP anyway. These are scenarios without path
>>> redundancy or path transparency.    
>>
>> Why are you so confident about the path, when you cannot control whether
>> there is a PEP/spoofing box in it?
>>
> 
> Honestly, I don´t understand the question.
> 
> I wrote: "The only scenrios where I see a justification / necessity for
> doing
> 
> splitting or spoofing are scenarios where the TCP flow must pass the
> split box / spoofing box / PEP anyway. "
> 
> In other words: I restrict the use of split boxes to scenarios where
> there is no other path. Either the flow passes the box - or the flow
> passes away.

I do not agree that you have control over this restriction.

...
> Practically spoken: If the word "splitter" appears in the abstract of a
> paper submission, please don´t reject it immediately. Please read at
> least the introduction ;-)

A key aspect of such a review is whether the assumptions are realistic.
I do not consider "control over path", as above, a realistic assumption
for splitters you do not control.

>>> To be not misunderstood: I don´t want to make restrictions for the
>>> benefit of a splitter. I think in scenarios where an alternative path to
>>> a splitter exist, a splitter must not be used.
>>>     
>>
>> Either the use of splitters is under your control or it is not.
>>
>>   
> 
> From my assumptions / restrictions it clearly _is_. And if you feel more
> comfortable that way we perfectly can integrate some kind of option or
> switch in a mobile network´s UNI where the user has the choise whether a
> splitter shall be allowed or shall be forbidden. 

I don't believe this is useful. People who deploy splitters that are
intended to be found, simply, do not - they deploy proxies. The whole
point of a splitter is to be transparent - either for backward
compatibility with devices that aren't capable of working with a proxy,
or to deliberately hide their presence.

> So the use of a
> splitter must not be transparent but explicitely granted / requested by
> a user. We have similar options for transcoders / WWW proxies in mobile
> networks here in Germany. IIRC, E-plus offers optional transcoders /
> application level PEP.

As noted above, I don't believe this is a viable case for TCP splitters.

...
> I perfectly understand why you are strongly opposed against splitters
> and the reasons are compelling. However, when in a particular situation
> a splitter is the only yet known possibility e.g. to achieve acceptable
> throughput for a flow within a settling time of 10 seconds instead of 10
> minutes ore more, then we should consider giving the user the option to
> allow splitting.

It would be useful to show such a case. I do not believe there is a case
where a splitter works where a proxy would not - or would not be more
appropriate.

>>> In my opinion splitters
>>> are to be used with maximum care and only in exceptional cases where any
>>> known alternative is worse than a splitter.
>>
>> It would be interesting if you could explain a sample case. 
> 
> IIRC, Mark Allman has published some interesing work where he used
> splitters for  satellite  / deep space networks.
> To my understanding the major concern was the extremely large time TCP
> needs to fill the line here.

In that case the splitter is either isomorphic to a proxy, or it is
spoofing the sender into violating current TCP congestion profiles. It'd
be useful for Mark to comment on this to clarify.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070117/082e4f87/signature.bin