Re: [Spud] Connect and ACK Bits: Why?

[Mirja Kühlewind <[e-mail]>]

Hi Jacob,

I believe nobody answered this mail so far, so I’ll have a try. We’ve been discussing this a lot and also have not decided if we will need these flags or not. See further below.


> Am 08.07.2015 um 19:32 schrieb Jacob Chappell <[e-mail]>om>:
> 
> Good afternoon, everyone.
> 
> There's been something bothering me since I started working with SPUD. Now that I realize there's a mailing list, I figure why not ask here?
> 
> My question is, why is connect/ack part of the SPUD protocol? The purpose of these commands does not seem clear from the draft.

May I ask which draft you are referring here? The prototype draft really only is a prototype which mean one example protocol that might or might not address the needs. In the mean time there is also a requirement draft as well as a use case draft that are basically independent of the finally protocol design. The both also suggest to have a start flag as well as an ACK and maybe give slightly more discussion on this (but might also need more discussion). While it is less clear if we actually need a start bit, we definitely would like to require SPUD to basically send an ACK… see below.

> For one, SPUD runs over UDP, so there's no guarantee the connect or ack will even make it to the other side. Second, a previous message on this mailing list from the archives indicates that you don't even have to wait for an ack to send a data packet. This makes sense, because the ack may be lost in transit (or maybe the original connect was lost in transit). But if this is the case, what's the point in even having connect/ack as part of the protocol?

The idea is to assist network devices to set up state. E.g. a firewall might forward the connect/start packet to the receiver behind the firewall but is only willing to forward additional packets if the receiver send at least one packet to confirm that this is a wanted connection. That’s why we think an ACK is useful.

The connect/start is rather to distinguish if there actually is a newly starting flow or a middlebox only sees the middle of a flow because the flow was e.g. rerouted. In this case the middlebox might not be willing to sst up state but maybe sends an error message to the sender instead. As I said this is all still under discussion.

The question if you are going to resent a connect/start packet in SPUD because it or the corresponding ACK packet was lost depends on the higher layer protocol you are using over SPUD. SPUD (over UDP) is not indented to be used as a stand-alone transport protocol but is rather a shim layer between network and transport. So you could have e.g. TCP over SPUD over UDP or UDP over SPUD over UDP. In case of TCP you probably retransmit the SYN and therefore also the SPUD connect. In case of UDP you might not retransmit and simply try to send data without knowing if they will be received or not as your application might do it over UDP today as well.

> 
> It seems like a possible alternative would be to just send data packets spontaneously. The client can just be sure to generate a new tube ID when sending to a new destination/port pair, and maintain that state. Ultimately, you're going to have to use timers to expire state in case of packet loss, so why not just use timers exclusively?

As described above it’s more about network state then client state. However, you probably will always need timers because you can never be sure that certain information will be delivered. However, if you can get more explicitly signals (and that’s why we also would like to have a SPUD finish/stop packet) you can assist network nodes as well as end host to e.g remove state quicker  and maybe also use SPUD to set timer values correctly (see the use case draft).

Mirja


> 
> Jacob Chappell
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud