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

From: "zhangyali (D)" <[email-masked]>
Date: Thu, 1 Jun 2017 08:27:25 +0000

Hi all,

I notice that TCP mechanism does not require data packets and their ACKs share the same path, that is simple implemented in the network. But some problems may happen if the sender does not perceive it. For example, the data packet is transmitted successfully without any congestion, while the ACK packet is dropped since it  goes through a very congested path. But the sender could not ascertain the real reason of "the data packet is lost". If this event repeats three times, the sender will cut its window by half wrongly, which will hurt its throughput. But in effect, this bad phenomenon should not happen  if the ACK packet go through any uncongested way.

Best Regards,
Yali

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Thu, 1 Jun 2017 11:14:57 +0200

Hi Yali,

this is not what will happen typically; As ACKs are cumulative, and often contains additional information about lost data packets (SACK option) and timing (timestamps), all the sender needs is a fraction of ACKs (depending on bandwidth-delay product and current state of the sender) for it to utilize most of the forward path.

Also, when the return (ACK) path is heavily congested, it's arguably a good idea for the sender to throttle the sending rate, in order to reduce the number of ACKs contributing to congestion on the return path...

Btw - ACK thinning (deliberate dropping of some ACKs) has been observed on some paths...

Best regards,
   Richard

  ----- Original Message ----- 
  From: zhangyali (D) 
  To: [email-masked] 
  Sent: Thursday, June 01, 2017 10:27 AM
  Subject: [tcpm] How about data packets and ACKs go through different paths?

  Hi all,

  Best Regards,

  Yali

       Virus-free. www.avg.com  

------------------------------------------------------------------------------

  _______________________________________________
  tcpm mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Jun 2017 10:35:57 -0700

On 6/1/2017 1:27 AM, zhangyali (D) wrote:
>
> Hi all,
>
>  
>
> I notice that TCP mechanism does not require data packets and their
> ACKs share the same path,
>
The Internet does not require that forward and reverse paths are identical.

> that is simple implemented in the network. But some problems may
> happen if the sender does not perceive it. For example, the data
> packet is transmitted successfully without any congestion, while the
> ACK packet is dropped since it  goes through a very congested path.
>
If ACKs are dropped due to congestion, then backing off transmission
might be a valid response.

However, as Richard noted, ACKs are cumulative, so if any of the later
ACKs get through, the system may slow down (due to the increased delay
and bursting) but won't necessarily backoff.

> ut the sender could not ascertain the real reason of “the data packet
> is lost”.
>
TCP always interprets loss as congestion, because it is safer than
assuming otherwise (e.g., corruption, which would expect immediate
retransmission).

> If this event repeats three times, the sender will cut its window by
> half wrongly, which will hurt its throughput....
>

Again, maybe that's actually a good thing.

Joe

---

From: "zhangyali (D)" <[email-masked]>
Date: Fri, 2 Jun 2017 01:49:22 +0000

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.

Best,
Yali

发件人: Richard Scheffenegger [mailto:[email-masked]]
发送时间: 2017年6月1日 17:15
收件人: zhangyali (D) <[email-masked]>; [email-masked]
主题: Re: [tcpm] How about data packets and ACKs go through different paths?

Hi Yali,

Best regards,
   Richard

----- Original Message -----
From: zhangyali (D)<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Sent: Thursday, June 01, 2017 10:27 AM
Subject: [tcpm] How about data packets and ACKs go through different paths?

Hi all,

I notice that TCP mechanism does not require data packets and their ACKs share the same path, that is simple implemented in the network. But some problems may happen if the sender does not perceive it. For example, the data packet is transmitted successfully without any congestion, while the ACK packet is dropped since it  goes through a very congested path. But the sender could not ascertain the real reason of “the data packet is lost”. If this event repeats three times, the sender will cut its window by half wrongly, which will hurt its throughput. But in effect, this bad phenomenon should not happen  if the ACK packet go through any uncongested way.

Best Regards,
Yali

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png]<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Virus-free. www.avg.com<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

________________________________
_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 1 Jun 2017 22:12:02 -0700

On Thu, Jun 1, 2017 at 6:49 PM, zhangyali (D) <[email-masked]>
wrote:

> 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