Re: [Spud] Return routability and feedback (was: Questions based on draft-trammell-spud-req-00)

[Ted Hardie <[e-mail]>]

On Tue, Aug 11, 2015 at 10:59 AM, Jana Iyengar <[e-mail]> wrote:

> A quick thought on explicit close, FWIW. Sending an explicit close packet
> often involves a client or a server sending a packet, usually after some
> amount of quiescence. When on a cellular device, this requires the device
> to pull up the radio and spend energy on sending/receiving a packet that
> basically contains little to no information. This design is generally being
> eschewed in favor of a connection timeout at the ends, especially when the
> endpoints can negotiate on a timeout period.
>
> ​

​So, the problem with this approach is that the negotiation of the timeout
period doesn't involve just the endpoints; it involves the network elements
that are maintain state and allocations.  To keep them at their task, lots
of systems send heartbeat packets at regular intervals when no other
traffic is present.  Those also wake the radio and consume battery.​

So, whether the trade-off with an explicit close is worth may depend on the
traffic pattern of the application and the state being held in the
network.  In some cases, the close message would go with the last packet,
and so be "free" from a radio perspective.   I'd  guess that it would
generally be worth it in any system containing a SPUD-compliant NAT or STUN
server, but there are cases (DNS over SPUD) where even then it might not be
a win for the client.

But the client itself is the best judge of this, which is why I favor
including the functionality, but making it optional.  All the systems have
to be redundant to that packet being lost anyway.


> One way for a middlebox to learn about connection close would be to have
> an explicit negotiation in SPUD that is visible to the network... but I
> don't think that relying on connection close packets for signaling a
> connection's termination is going to be adequate.
>
>
​From a coding perspective, that seems to be really painful.  When some
Harry Potter app uses 17 second timeouts in homage to the Galleon, it's
going to need custom timers.

Ted


> On Tue, Aug 11, 2015 at 2:38 AM, Mirja Kühlewind <
> [e-mail]> wrote:
>
>> Hi Roland,
>>
>> see below.
>>
>> > Am 11.08.2015 um 09:23 schrieb Roland Bless <[e-mail]>du>:
>> >
>> > Hi,
>> >
>> > Am 08.08.2015 um 11:16 schrieb Mirja Kühlewind:
>> >> 4) Return routability and feedback —-
>> >>
>> >> a) 2WHS vs. 3WHS? —> SPUD should/must (?) provide a 2WHS, that means
>> >> an ACK in response to the initial packet should be generated by SPUD
>> >> even if the overlying protocol does not support this semantic. Note
>> >> this mean the ACK may only have a SPUD header but no overlying
>> >> protocol data.  This would make all SPUD flows/tubes bidirectional.
>> >
>> > But potentially hitting different middleboxes along asymmetric paths,
>> > i.e., the ACK is routed back along a different path than the initial
>> > packet. A 2WHS is also vulnerable against state exhaustion attacks.
>> >
>> >> Further SPUD should also provided the semantics for an 3WHS but may
>> >> only send a third packet if the overlying protocol implements it or
>> >> there is another reason for the application to explicitly request a
>> >> SPUD-only 3WHS.
>> >
>> >> From a security perspective, a 3WHS with a DoS protection cookie would
>> > be the most reasonable option.
>> >
>> >> b) Does the semantics of the SPUD protocol need to provide an
>> >> explicit start signal as well as start/ack signal? -> Yes, start is
>> >> needed to distinguish start and middle of a tube; ack is needed to
>> >> finally set up state. However, not clear yet if all SPUD tubes MUST
>> >> send a start signal or only SHOULD. If a start was received, however,
>> >> a ACK must be sent…?
>> >
>> > See above. On the one hand an ACK is maybe not enough to set up state. A
>> > SYN Flood would otherwise also set up state in the SPUD box. On the
>> > other hand, SPUD boxes must be prepared to react to flows/tubes that
>> > neither have Start, ACK, or Close due to temporary re-routing events.
>> >
>> >> c) Should it be possible to send multiple START signal on the same
>> >> tube (e.g to re-initiate state)? -> Not clear if this is really
>> >> needed
>> >
>> > I don't think that it is needed, see previous point.
>> >
>> >> c) Is a stop flag needed/useful? —> Yes (faster state tear-down), but
>> >> the overlying protocol must be resilient to it not being sent, not
>> >> being received.​
>> >
>> > I don't understand this, is that different from a close?
>>
>> No, it’s close. The question is do we need an explicate signal for close
>> (and maybe even close/ack) or is it sufficient to just let the state time
>> out because middleboxes anyway need a timer as they can never rely on
>> seeing a close.
>>
>> Mirja
>>
>> >
>> > Regards,
>> > Roland
>> >
>> > _______________________________________________
>> > Spud mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/spud
>>
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud
>>
>
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>
>