No CancellationToken still?

[Leonardo-Ferreira]

Despite generating async methods, those don't have cancellation tokens... are there plans to change this?

[mconnew]

This is quite a complicated issue. The first question is what would you expect a cancellation to do? Is it just local or do you want it to cancel the operation on the service side?

Local cancellation

Canceling an operation locally would require aborting of the channel. The layer of WCF that handles the contract and converting it into a SOAP message has no knowledge of anything below that. It just creates a request SOAP message, and if not one way, waits for the reply. If using a Request/Reply shaped transport like HTTP, you could do something like pass the cancellation token to the HttpClient.SendAsync call. This would cause the underlying socket being used to send/receive the request to be forcefully closed (RST). But when you start talking about a channel using ReliableSessions, that would just trigger the request being sent again. Deciding you don't want the response any more would mess up the accounting done by reliable sessions. In that scenario, the only option is to abandon the session, which means faulting the channel.
With a duplex channel like NetTcp, you have a single persistent connection for all requests for a single channel. You can have multiple overlapping requests in progress. If you close the socket, you fault the channel anyway (unless using ReliableSessions, then you have the same problem as HTTP with RS). You could just decide you don't want the response, and when it arrives, ignore it. But you can just stop waiting for the response anyway and it's the same thing, you don't need cancellation.
Basically to do local cancellation, the only options are to allow the response to come back and ignore it (which you can do yourself without WCF cooperation), or abort the channel (which again you can do yourself without WCF cooperation).

End to end cancelation

This is the interesting scenario, and how I would want to implement things. The way I would do it is define a new custom SOAP header which is a non-required header (must understand is false) which identifies a cancellation id. When the provided CancellationToken is canceled, a special SOAP message is sent with an action defined which communicates a cancellation has been requested. In the body, it would send the cancellation id. On the service side, a CancellationTokenSource would be created which is recorded against the cancellation id. The CancellationToken from that source is passed to the operation. On receiving a message with the cancellation action, the specified id is used to lookup the CancellationTokenSource and cancel it. It would be up to the operation implementation on what to do. If it throws a OperationCancelledException, a special fault handler would convert that to a known fault reason and a Fault message returned, which on the client side would get thrown as an OperationCancelledException.
This requires modifying the contract parsing code to understand about CancellationToken, adding this conceptually to the OperationDescription which doesn't mess with the message description. The same would need to happen on the service side too.
I've wanted to make end to end cancellation work for a long time. The problem is the service side would only be implemented in CoreWCF and not in .NET Framework.

As you can see, local cancellation isn't work doing. End-to-end is a lot of work. Would sample code using already available extensibility be an option? You couldn't have the CancellationToken on the interface contract, but you would do something like this:
Client Side

var factory = new ChannelFactory<IService>(binding, endpoint);
factory.AddCancellationSupport(); // Extension method that adds a behavior

using(var scope = new OperationContextScope((IContextChannel)channel))
{
    var cts = new CancellationTokenSource(TimeSpan.FromSeconds(20));
    OperationContext.Current.SetCancellationToken(cts.Token); // Extension method adds token to OC
    try
    {
        await channel.DoSomethingAsync();
    }
    catch(OperationCancelledException oce)
    {
        // do something with oce
    }
}

Service Side

// Add behavior to service, different method for WCF and CoreWCF so won't detail it here

public class Service : IService
{
    public Task DoSomethingAsync()
    {
        var ct = OperationContext.Current.GetCancellationToken(); // Extension method gets token that was added by behavior
        await someclass.DoWorkForMeAsync(ct);
     }
}

Would a code sample which worked like above (although clunky, it's functional) work for you? If using CoreWCF with injection support, you could potentially do this:

public class Service : IService
{
    public Task DoSomethingAsync([Injected]CancellationToken ct)
    {
        await someclass.DoWorkForMeAsync(ct);
     }
}

But I don't know if it's a great idea to inject cancellation tokens via DI. Maybe a holder class with a Token property?

[Leonardo-Ferreira]

Let me give you more details about my case @mconnew.

On the client side, I have a microservice architecture, where the api pods are quite small (0.2 cpu, 128 mem) and not that plentiful (from 3 to 10 replicas) and we handle up to 280-300 req/s
ON the server side, I have a monolith, UBER over-sized (think like 4 machines, each using 2 out of 64 cores) running on collocated hardware...

The client side is quite susceptible to "hiccups" on the server side, specially on peak moments, like lunch and dinner time, so on the client side we enforce a 3 sec timeout: this way, we can "free" the incoming connections. The problem is that we don't actually free the outgoing connections to the big monolith server and they can live up to TWO MINUTES. At a request rate of peak hours, we are talking easily 10-15k connections "hanging" FOR EACH POD... when this happens, the pods simply drown... for the monolith server this is not a big issue (according to them) but for the client is.

Given this scenario, and the fact that the actual communication happens over http1.1 which does not multiplex the channel, killing the connection on the client seems very reasonable and acceptable to me

[mconnew]

I suspect they are living up to 1 minute, unless you've changed the SendTimeout on your binding to 2 minutes. The client will allow up to SendTimeout amount of time before it aborts the request. On .NET, this is done indirectly by passing a CancellationToken to HttpClient.SendAsync. On .NET Framework, we either set the timeout on HttpWebRequest (only for sync calls) or create a background timer which aborts the request (only for async calls).

Depending on how you use your client channels will determine how you manage things. Do you have multiple operations where some need the longer timeout and some need the 3 second timeout or would the 3 second timeout apply for all calls? Do you use a single client channel instance from multiple threads at the same time? Would you want the 3 second timeout for all times of the day or only at peak?

The simple approach is to set the SendTimeout on your binding to 3 second. But if you don't want it for all requests all the time, then there are other ways to control the timeout. If you cast your client channel to IClientChannel, there's a property called OperationTimeout which allows you to modify the SendTimeout on a per channel basis after it's been created. So for example if you only want a 3 second timeout at peak hours, you could check the time and case your channel to IClientChannel and set the OperationTimeout to 3 seconds. When you get out of the peak hours, set it to a higher value.

If you have some operations you want a higher timeout for, you can set the OperationTimeout just before each call. This can become tricky if you have multiple threads using the same channel instance that would want different timeouts. At some point after the operation call has been made, and before the actual Http request is made, the OperationTimeout is copied into the current requests context. If you have multiple threads using the same channel instance with different timeouts, you could have a different thread set the OperationTimeout to an undesired value before it's copied on the current thread. If you're doing async calls, there is a non-trivial workaround (basically hold a lock until the incomplete Task is returned at which point the timeout has been copied, then release the lock and await the Task) which is probably more hassle than just not sharing the channel instance between threads.

[mconnew]

@Leonardo-Ferreira, did my prior comment address your needs?