Hi Kewin,I am not sure if I got your idea 100% so let me rephrase it. You
want to have a policy analogous to transmission_control_policy in the DTP
to react to ECN marked packets?
Why that?
To me it has no sense since you already have that in DTCP (flow control).
As you said, if you decide to allocate (an application/ipcp requests) a not
reliable nor controlled flow) why would you care about ECN flags? Maybe I
miss interpreted your idea, but at least for the use case you propose I do
not agree with it. The solution is already there and use a DTP+DTCP
supported flow.
Best,
Leo
2015-10-21 10:04 GMT+02:00 Kewin Rausch <kewin.rausch@xxxxxxxxxxxxxx>:
Hi everyone,
I recently inserted a new policy hook at DTP kernel level policy set in my
branch of Irati stack implementation. Such new hook is on the receiving
'path' of the DTP, in order to have an hook not only on the transmission
side, but also on the receiving one.
Policy like the ECN marking i recently developed mark the packet
regardless of the profile used for the communication(with or without
control), but there's actually no way to realize that condition in DTP only.
True is that using only DTP does not allow to control the flow itself, so
even if you realize that there's a congestion you can't take action to
avoid it. Still this is a particular problem and there can be a more
generic case.
Realizing that something is happening on the network(and operate on the
flow) could be useful, even with the limited control offered by DTP(well,
no control).
But again, I'm thinking in the term of the specific case of ECN, to bring
an example. The idea is to have a counterpart of transmission policy on the
receiving side.
What do you think about this? :)
Cheers,
Kewin R.
