Re: [Spud] SPUD's open/close are unconvincing

[Tom Herbert <[e-mail]>]

On Wed, Apr 8, 2015 at 6:22 PM, Toerless Eckert <[e-mail]> wrote:
> On Wed, Apr 08, 2015 at 06:21:21PM -0400, Daniel Kahn Gillmor wrote:
>> >    What is the best possible design we can do to make UDP flows
>> >    be equal or better permissible across WELL BEHAVED FW and similar
>> >    middleboxes ? Please define "WELL BEHAVED"as part of your answer.
>>
>> As i wrote to Joe, i'm not convinced that this is an answerable question
>> considering that no one has provided a technical argument yet for why
>> the enterprise firewall operators can't already do what we're talking
>> about here.
>
> Sorry, i need to give a multi-tiered answer:
>
> A) Lowest layer what i said initiall - mobility, load-splitting,
> multiplexing.
>
> B) Next layer: Yes, the FW admin could do for UDP what she does for TCP,
> but in todays ecosystem she will not:
>
>    UDP has
>      I) bad karma due to history of bad UDP apps in the past
>     II) More filtering on UDP than equivalent TCP traffic because
>         there is so much business critical TCP crap
>    III) not a lot of business critical apps riding on UDP
>     IV) A historic architecture view of "doing reliable transport
>         on top of UDP is a bad, undesirable workaround"
>
>    Seeded by I, II-IV form a vicious cycle.
>
> C) Decades long a ridiculously slow and cumbersome evolution
>    of transport layer functionality. We should have done the bloody
>    AQM work a decade or more ago.
>
>    Reason IMHO is that transport layer is in the kernel, resulting
>    in a totally broken agility model for transport layer
>    compared to middleware/app-layer (which created .
>
> Alltogether this means to me the goal of the SPUD exercise
> architecturally is:
>
> Redefine the Internet architecture to say:
>
>  -> Transport Layer needs to be split up into sub-layers:
>
>     1) application multiplexing layer - UDP, (running in OS) unchanged
>     2) common, middlebox friendly connection/packet signaling layer
>     3) transport connection QoE  layer
>        (reliability (FEC,ARQ), rate-control, measurement, jitter control,...)
>        Aka: short term just existing Internet transport protocols
>        (RTP, TCP, SCTP,...) but if one would design a new transport
>        protocol, one could not redo whats already in 2).
>
>     2) and 3) can run in app/middleware (per app) and/or in kernel.
>
> SPUD is the first attempt at 2).
>
> If we wouldn't do 2), but just 3) over 1), we will make the
> chicken & egg problem of 1) even worse, because we're just asking
> FWs to now inspect multiple reliable transports inside UDP instead
> of (with 2) giving them one common single layer to inspect. And
> of course we also do not solve C), because there is just a bunch
> of things like mobility, load-splitting, per-packet marking and so
> on that we know we cold get from the network to benefit apps, but
> without moving it into user-land, it's not going to go anywhere fast.
>
I think the kernel/user-land argument is a red herring. The problem is
that middleboxes routinely participate in transport layer protocols
which was never architected-- transport layer protocols are inherently
end-to-end protocols.  It's relatively easy to change client and
server sides to accommodate new transport functionality, but pretty
much impossible for us to change all the possible middleboxes in a
path in a timely fashion. Just one middlebox in the path that decides
to drop our packet because it doesn't understand our new option, or
doesn't like our new flags can spoil everything-- it is really
difficult to work around interoperabilities like this.  So, yes, the
net effect of this is that we have become very conservative with
transport layer changes, and when we do make changes at the transport
layer we often have to masquerade these in something that is
considered generally palatable to middleboxes. This is why we intend
to run transport protocols over UDP in the first place, and has even
motivated brazen attempts to overload TCP protocol number with other
things (e.g. STT). SPUD is a good opportunity to generalize and
standardize middlebox/transport protocol interactions, but if the its
benefits are dependent on middleboxes being updated that not is going
to go anywhere fast either!

>> > c) If i read it correctly, SPUD can
>> >
>> >    a) set up potentially multiple independent pipes across the same 5-tuple.
>> >    b) A single pipe can go across different 5-tuples (multipath/mobility).
>> >
>> >    These two features should explain why tracking 5-tuple as you
>> >    suggest alone would not be sufficient.
>> >
>> >    Btw: I am a fan of b), i don't think a) should be encouraged given
>> >    experience with RTCweb. In that sense, the total number of
>> >    pipes would even be equal or smaller than the number of 5 tuples.
>>
>> This is an interesting point, thanks.  I'd be curious to hear more
>> details about the RTCweb experience that have convinced you that (a)
>> should not be encouraged.
>
> Yeah, let me reword, first time around it wasn't precise:
>
> If an RTCweb session requires 10 5-tuple flows, it may take
> 10 times as long to set it up, and you may end up with 1/10'th maximum
> number of parallel sessions due to the number of NAT/FW 5-tuple pinholes
> you need to build.  Because we want NAT/FW to be SPUD tube aware,
> SPUD SHOULD NOT go out and claim:
>
> "you can replace 10 5-tuple UDP flows with 1 UDP flow with 10 SPUD tubes,
>  and your NAT/FW pinhole problem goes away".
>
> Aka: An RTCweb app worried about pinhole setup should opt for one
> Tube, but that in itself would already give it a lot of other benefits
> mobility, load-splitting, per-packet-marking,....
>
> Btw: IMHO performance of NAT/FW pinhole setup is not a limiting factor
> if you just buy the right NAT/FW product, but i do by now don't
> think anymore that all packets of a transport level session should
> have the same QoS.
>
> SPUD can solve this as well with per-packet markings, and
> once you have that, the only reason why you would want multiple
> tubes for an app-session IMHO is if you explicitly want to give
> FWs the ability to disect your traffic (eg: drop the video portion
> but permit audio).
>
>> The trouble with (b), of course, is that in the multipath or mobility
>> case, the tube will continue its flow over different network segments,
>> which violates the goals people have described for open and close.
>>
>> As i move to a new path, i'm deliberately not sending a Close message
>> (because i want to keep the tube open, right?) -- so what do the
>> middleboxes do?
>
> I think the first order of business was not to be worse than TCP,
> but not yet trying to finalize what the most widely agreeable improvements
> beyond that are.
>
>> And after i've moved to a new network and want to continue the same
>> tube, surely i won't indicate that the flow is opening (it's already
>> open).  As a result, the equipment on the new path won't see the Open
>> message -- should they discard it now?
>>
>> These arrangements seem in conflict to me.
>
> I can think of ways to improve the signaling. The main
> issue is the IETFs history of onpath signaling and the resulting
> resistance forces in the IETF against touching that subject.
>
> But consider the opportunity that redunant or cluster of
> NAT/FW will share SPUD tunnel-IDs amongst them to support
> the mobility case. No new standardized signaling required.
>
> Cheers
>     Toerless
>
>> Regards,
>>
>>         --dkg
>>
>> > P.S.: Cool domain name. Is that indicative of the role you're planning
>> > to take in the discussion ? ;-))) (sorry, i can never resists these questions).
>>
>> :)
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud