Subject: Re: [tcpm] ??: How about data packets and ACKs go through different paths?

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 5 Jun 2017 07:55:04 +0000

Hi

LEDBAT (rfc6817) is one example that estimated one way queue delay based on ACK timestamps, SCReAM (https://tools.ietf.org/wg/rmcat/draft-ietf-rmcat-scream-cc/ ) for real time media is another example , yet another example suggest a slight modification to Cubic (https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 )
The positive thing is that there is less impact from congestion in the ACK return path. 
There are however some less good properties. 
1) Late comers advantage
2) The timestamp clock in the remote end must be known

#2 above may be solved for Linux clients/servers, I recall that support for 1000Hz time base for timestamps is being added ?

/Ingemar

> Date: Thu, 1 Jun 2017 22:12:02 -0700
> From: Yoshifumi Nishida <[email-masked]>
> To: "zhangyali (D)" <[email-masked]>
> Cc: Richard Scheffenegger <[email-masked]>, "[email-masked]"
> 	<[email-masked]>
> Subject: Re: [tcpm] ??: How about data packets and ACKs go through
> 	different paths?
> Message-ID:
> 	<CAO249yfC2TR+D+hzCk7nb4aZyLZ4VARUFRCM4DNoni6-
> [email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> On Thu, Jun 1, 2017 at 6:49 PM, zhangyali (D) <[email-masked]>
> wrote:
> 
> > Hi Richard,
> >
> >
> >
> > Thank you for your prompt reply.
> >
> >
> >
> > Indeed, sender should decelerate to ease congestion if it finds ACK
> > packet has been dropped. But that relate to how to achieve a high
> > utilization of network resource. A simple think is that network
> > utilization will be lower if sender do not differ the congestion
> > degree between data packet path and ack packet path.
> >
> >
> >
> > Another question is that some congestion control mechanism take use of
> > delay measured by ACK timestamps to denote congestion degree. If data
> > packets and their ACK packets go through different ways, the
> > measurement of delay may confuse reverse path congestion experienced
> > by ACKs with forward path congestion experienced by data packets. I
> > think Vegas, a delay-based congestion control mechanism, will experience
> this problem.
> >
> 
> Right, I think you'll need to measure one-way delay, which vegas doesn't.
> --
> Yoshi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20170601/920
> 97e40/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> ------------------------------
> 
> End of tcpm Digest, Vol 158, Issue 2
> ************************************