Subject: [tsvwg] New Version Notification for draft-wang-tsvwg-tcp-coding-00.txt

From: "wangjinzhu" <[email-masked]>
Date: Sun, 8 Feb 2015 09:31:11 +0800

Hi all
   we have submitted a draft (draft-wang-tsvwg-tcp-coding-00) to discuss adding coding to the TCP to improve performance in wireless network. A coded tcp is proposed and we have done the test in the real network and found that TCP's throughput can be improved, especially in the public WiFi. The attachment records the test results.
   we think it is desired to give more attentions on combining TCP with coding. Any comments or suggestions will be greatly appreciated.

Best Regards

Jinzhu Wang (Jim Wang)
China Mobile

-----original text-----
Sender: [email-masked] [mailto:[email-masked]] 
Time: 2015年2月8日 9:18
Receiver: Deng Lingli; Jinzhu Wang; Lingli Deng; wangjinzhu
Title: New Version Notification for draft-wang-tsvwg-tcp-coding-00.txt

A new version of I-D, draft-wang-tsvwg-tcp-coding-00.txt
has been successfully submitted by Jinzhu Wang and posted to the IETF repository.

Name:		draft-wang-tsvwg-tcp-coding
Revision:	00
Title:		Combining TCP with coding in wireless network
Document date:	2015-02-08
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-wang-tsvwg-tcp-coding-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wang-tsvwg-tcp-coding/
Htmlized:       http://tools.ietf.org/html/draft-wang-tsvwg-tcp-coding-00

Abstract:
   This drat discusses combining TCP with coding in wireless network.  A
   lot of factors lead to unstable air-link in wireless network, which
   causes high bit error rate and thus high packet loss.  Since packet
   loss will degrade TCP throughput and coding can erase packet loss in
   transmission, combing TCP with coding can achieve better performance.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 9 Feb 2015 15:07:33 +0000

Hi,

under which conditions does your coded TCP grow or shrink its window? The ID doesn't discuss congestion control at all.

Lars

On 2015-2-8, at 02:31, wangjinzhu <[email-masked]> wrote:
> <coded TCP.pptx>

---

From: "wangjinzhu" <[email-masked]>
Date: Tue, 10 Feb 2015 14:03:40 +0800

Hi Lars
Thanks for your comment.
Please see inline.

Best Regards 
Jinzhu

> -----Original Text-----
> Sender: Eggert, Lars [mailto:[email-masked]] 
> date: 2015/2/9 23:08
> receiver: wangjinzhu
> cc: [email-masked]
> subject: Re: [tsvwg] New Version Notification for draft-wang-tsvwg-tcp-coding-00.txt

> under which conditions does your coded TCP grow or shrink its window? The ID doesn't discuss congestion control at all.

[Jinzhu] The coded TCP dose not modify the TCP's congestion control. At the sender side, it first encodes the original packets and then delivers the coded packets to the standard TCP stack to send. So, from the view of the standard TCP stack, it delivers the coded packets instead of the original packets. 
Thus, in coded TCP the congestion window is controlled by standard TCP congestion control algorithm. For example in the coded TCP prototype system, the TCP cubic is adopted. 

In the transmission, when packet loss occurs, if the receiver side can recover the loss by using redundancy (packet loss is low), the sender side does not see the packet loss and thus keep on increasing congestion window. On the other side, if the receiver side cannot recover the loss (packet loss is high), the sender sees the loss and decreases the congestion window. In both cases, the congestion window is controlled by the TCP congestion algorithm, e.g., TCP cubic

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 10 Feb 2015 07:57:55 +0000

Hi,

So, if there is congestion but the sender doesn't see the loss, the sender does not back off at all, right? Instead, over a congested network, the sender would even further increase the congestion window and its sending rate? Wouldn't this break Internet congestion control?

I guess greedy senders would increase the sending rate until the packet loss rate is so large that it cannot be recovered by redundancy any more (self-inflicted congestion). Therefore, the TCP connection would again have to fall back all the time to retransmission-based recovery, right?

Best regards

Michael

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of wangjinzhu
> Sent: Tuesday, February 10, 2015 7:04 AM
> To: 'Eggert, Lars'
> Cc: [email-masked]; '邓灵莉/Lingli Deng'
> Subject: Re: [tsvwg] New Version Notification for draft-wang-tsvwg-tcp-
> coding-00.txt
> 
> Hi Lars
> Thanks for your comment.
> Please see inline.
> 
> Best Regards
> Jinzhu
> 
> > -----Original Text-----
> > under which conditions does your coded TCP grow or shrink its window?
> The ID doesn't discuss congestion control at all.
> 
> [Jinzhu] The coded TCP dose not modify the TCP's congestion control. At
> the sender side, it first encodes the original packets and then
> delivers the coded packets to the standard TCP stack to send. So, from
> the view of the standard TCP stack, it delivers the coded packets
> instead of the original packets.
> Thus, in coded TCP the congestion window is controlled by standard TCP
> congestion control algorithm. For example in the coded TCP prototype
> system, the TCP cubic is adopted.
> 
> In the transmission, when packet loss occurs, if the receiver side can
> recover the loss by using redundancy (packet loss is low), the sender
> side does not see the packet loss and thus keep on increasing
> congestion window. On the other side, if the receiver side cannot
> recover the loss (packet loss is high), the sender sees the loss and
> decreases the congestion window. In both cases, the congestion window
> is controlled by the TCP congestion algorithm, e.g., TCP cubic
> 
> 
> > Lars
> 
> >>   we have submitted a draft (draft-wang-tsvwg-tcp-coding-00) to
> discuss adding coding to the TCP to improve performance in wireless
> network. A coded tcp is proposed and we have done the test in the real
> network and found that TCP's throughput can be improved, especially in
> the public WiFi. The attachment records the test results.
> >>  we think it is desired to give more attentions on combining TCP
> with coding. Any comments or suggestions will be greatly appreciated.
> >>
> >> Best Regards
> >>
> >> Jinzhu Wang (Jim Wang)
> >> China Mobile
> >>
> >> -----original text-----
> >> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >> <coded TCP.pptx>
> 
> 
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 10 Feb 2015 08:54:58 +0000

Hi,

I'm sorry, but this statement:

On 2015-2-10, at 07:03, wangjinzhu <[email-masked]> wrote:
> The coded TCP dose not modify the TCP's congestion control.

is contradicted by this statement:

> In the transmission, when packet loss occurs, if the receiver side can recover the loss by using redundancy (packet loss is low), the sender side does not see the packet loss and thus keep on increasing congestion window.

Your TCP seems to not reduce CWND if lost data can be recovered through coding, which is a change to standard TCP congestion control.

Lars

---

From: "Black, David" <[email-masked]>
Date: Tue, 10 Feb 2015 19:00:49 +0000

> Your TCP seems to not reduce CWND if lost data can be recovered through
> coding, which is a change to standard TCP congestion control.

+1 - the baseline approach should be ECN-like behavior where the recovered
data is delivered, but the loss is communicated to the sender in order to
cause the sender's congestion control logic to react (ECN treats a CE-marked
packet as if it were dropped).  I would suggest using at least the ECN
signaling, even if the packets aren't marked as using ECN, as  ECN has the
receiver-to-sender signaling worked out (i.e., please don't try to
reinvent that).

The bigger concern is that this draft's mechanism is intended for deployment
in an environment that exhibits high non-congestive losses, as described
in the Introduction:

   In wireless network, there are lot of factors (e.g., weather
   conditions, urban obstacles, multi-path interferences, limited
   coverage, mobility of the handset, etc.,) leading to unstable air-
   link.  As a result, wireless links exhibit much higher BERs than
   wired links.  Since all packet losses are considered as network
   congestion in standard TCP, packet loss caused by the high BER of the
   wireless link would trigger the TCP sender to reduce its sending rate
   unnecessarily.  This leads to the drastic decrease of TCP's
   throughput in the wireless network.

Unfortunately, this draft goes to the other extreme, and treats any
recoverable loss (and with good choice of coding algorithm, most of them
will be) as not indicating congestion.  As Lars notes, that's not
acceptable because it fails to react to recovered losses that do actually
indicate congestion.

There has been some prior work on trying to determine when a loss is
caused by congestion vs. link errors, but I can't quickly provide any
pointers - perhaps Lars can.

Thanks,
--David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Eggert, Lars
> Sent: Tuesday, February 10, 2015 3:55 AM
> To: wangjinzhu
> Cc: [email-masked]; 邓灵莉/Lingli Deng
> Subject: Re: [tsvwg] New Version Notification for draft-wang-tsvwg-tcp-coding-
> 00.txt
> 
> Hi,
> 
> recover the loss by using redundancy (packet loss is low), the sender side
> does not see the packet loss and thus keep on increasing congestion window.
> 
> Your TCP seems to not reduce CWND if lost data can be recovered through
> coding, which is a change to standard TCP congestion control.
> 
> Lars

---

From: "wangjinzhu" <[email-masked]>
Date: Thu, 12 Feb 2015 16:55:37 +0800

Hi Lars
I’m sorry for the confusing statement. Let me clarify it:
At the sender side, the coded TCP does not modify TCP’s congestion control
algorithm directly, it just delivers the coded packets to the standard TCP
stack to send. On the other hand, at the receiver side, when packet
received, it first checks whether the original packets of the coding block
can be decoded. If the number of the received coded packets is enough to
decode the coding block, it replies that all packets in the coding block
have been received successfully to the sender. This is a change to standard
TCP. 
Therefore, the congestion control is modified in coded TCP. Thanks for your
correction. 

Best regards,
Jinzhu

-----original text-----
Sender: Eggert, Lars [mailto:[email-masked]] 
Date: 2015.2.10 16:55
Receiver: wangjinzhu
CC: [email-masked]; 邓灵莉/Lingli Deng; [email-masked]
Subject: Re: [tsvwg] New Version Notification for
draft-wang-tsvwg-tcp-coding-00.txt

Hi,

Lars

---

From: "wangjinzhu" <[email-masked]>
Date: Thu, 12 Feb 2015 17:08:09 +0800

Hi Michael

Thanks for your comments.
Please see inline

Best Regards,
Jinzhu

> -----Original Text-----
> Sender: Scharf, Michael (Michael) [mailto:[email-masked]] 
> Date: 2015.2.10 15:58
> Receiver: wangjinzhu; 'Eggert, Lars'
> cc: [email-masked]; '邓灵莉/Lingli Deng'
> Subject: RE: [tsvwg] New Version Notification for draft-wang-tsvwg-tcp-coding-00.txt
>
> Hi,
>
> So, if there is congestion but the sender doesn't see the loss, the sender does not back off at all, right? Instead, over a congested network, the sender would even further 
> increase the congestion window and its sending rate? Wouldn't this break Internet congestion control?
>
> I guess greedy senders would increase the sending rate until the packet loss rate is so large that it cannot be recovered by redundancy any more (self-inflicted congestion). 
> Therefore, the TCP connection would again have to fall back all the time to retransmission-based recovery, right?

[Jinzhu] Yes. In coded TCP, if packet loss can be recovered by the receiver side by using redundancy coding, the sender doesn’t see the loss and thus does not back off. Currently the coded TCP cannot distinguish the random loss caused by unstable air-link from the congestion loss, thus if the packet loss is caused by congestion, the sender still increases sending rate until the packet loss cannot be recovered by redundancy. Then the sender reacts to packet loss and decreases the sending rate according to the standard TCP congestion control.

[Jinzhu] On the one hand, if the network can notify the congestion explicitly to the coded TCP sender, it can response congestion and decrease sending rate in order to eliminate congestion. The ECN is an important mechanism that can be combined with coded TCP. I think how to combine ECN with coded TCP needs further discussions. 

[Jinzhu] On the other hand, if the network does not feedback congestion to the coded TCP sender, it cannot distinguish the random loss from the congestion loss. In this case, only when the redundancy cannot recovery packet loss, the coded tcp sender decreases sending rate. Although this behavior is different to current Internet congestion control, it can control congestion by another way. For example, we set the redundancy as 10% in the coded TCP. In the standard TCP, when the network bottleneck utilization achieves to 100%, the TCP sender reduces sending rate to response the congestion (this is just a simple illustration, the 100% is inaccurate). While in the coded TCP, when the bottleneck utilization achieves to a higher value (perhaps 110%), the redundancy cannot recover the packet loss and thus the coded TCP sender reduces the sending rate to control Internet congestion. Currently, I’m not sure whether this behavior will impact the network or it will works well in the network. Discussions and suggestions will be greatly appreciated.

>> draft-wang-tsvwg-tcp- coding-00.txt
>> 
>> Hi Lars
>> Thanks for your comment.
>> Please see inline.
>> 
>> Best Regards
>> Jinzhu
>> 
>> > -----Original Text-----
>> [Jinzhu] The coded TCP dose not modify the TCP's congestion control. 
>> At the sender side, it first encodes the original packets and then

---

From: "wangjinzhu" <[email-masked]>
Date: Thu, 12 Feb 2015 17:24:29 +0800

Hi David

Best regards,
Jinzhu

> -----Original Text----
> Sender: Black, David [mailto:[email-masked]] 
> Date: 2015.2.11 3:01
> Receiver: Eggert, Lars; wangjinzhu
> cc: [email-masked]; 邓灵莉/Lingli Deng
>> Your TCP seems to not reduce CWND if lost data can be recovered 
>> through coding, which is a change to standard TCP congestion control.
>
receiver-to-sender signaling worked out (i.e., please don't try to reinvent
that).

[Jinzhu] Thanks, this suggestion is important to coded TCP. By using ECN,
the network congestion can be explicitly notified and the sender can adjust
congestion window timely when congestion occurs. I will work on it and
further update the draft to combine coded TCP with ECN.

>The bigger concern is that this draft's mechanism is intended for
deployment in an environment that exhibits high non-congestive losses, as
described in the Introduction:
recoverable loss (and with good choice of coding algorithm, most of them
will be) as not indicating congestion.  As Lars notes, that's not acceptable
because it fails to react to recovered losses that do actually indicate
congestion.
>
>There has been some prior work on trying to determine when a loss is caused
by congestion vs. link errors, but I can't quickly provide any pointers -
perhaps Lars can.

[Jinzhu] Yes, we are trying to recover link error loss at the receiver side
by using redundancy coding. However, since the coded TCP sender cannot
distinguish wireless link error loss from congestion loss, it treat the link
error loss the same as the congestion loss. 

[Jinzhu] I think the work on distinguishing link error loss from congestion
loss can be classified into explicit solution and implicit solution. ECN
belongs to the explicit solution. The explicit solution requires routers to
disclose the network state and in some cases may not be easy to be deployed
since some routers may not enable ECN. Thus if the implicit solution can be
applied to the coded TCP, it will be easier to be deployed. I’m not sure
whether there is a method that can distinguish link error loss from
congestion loss without the feedback from the network. Suggestions on the
implicit solution will be greatly appreciated. 

[Jinzhu] On the other hand, in the current coded TCP even if it cannot
distinguish the random loss from the congestion loss, it can control
congestion by another way, though this behavior is different to current
Internet congestion control. For example, we set the redundancy as 10% in
the coded TCP. In the standard TCP, when the network bottleneck utilization
achieves to 100%, the TCP sender reduces sending rate to response the
congestion (this is just a simple illustration, the 100% is inaccurate).
While in the coded TCP, when the bottleneck utilization achieves to a higher
value (perhaps 110%), the redundancy cannot recover loss and thus the coded
TCP sender reduces the sending rate to control Internet congestion.
Currently, I’m not sure whether this behavior will impact the network or it
will works well in the network. Discussions and suggestions will be greatly
appreciated

>> draft-wang-tsvwg-tcp-coding- 00.txt
>> 
>> Hi,
>> 
> >side does not see the packet loss and thus keep on increasing congestion
window.
>> 
>> Your TCP seems to not reduce CWND if lost data can be recovered 
> >through coding, which is a change to standard TCP congestion control.
>> 
> >Lars

---

From: "Black, David" <[email-masked]>
Date: Thu, 12 Feb 2015 23:50:21 +0000

Jinzhu,

> further update the draft to combine coded TCP with ECN.

That helps, but it's not that simple, sorry ...

When ECN is used, drops may still indicate congestion (i.e., use of ECN does
not result in all drops being due to link errors or the like and never due
to congestion).  There are at least two reasons for this:

	- Bottleneck is at a node that does not implement ECN and hence drops
		instead of applying a CE mark.
	- ECN-using node gets sufficiently overloaded that it has to drop
		instead of forwarding with a CE mark.

The primary piece of ECN that I'm recommending that you use is the
receiver-to-sender TCP signaling (i.e., the CWR and ECE flags, and
associated procedures - see Section 6 of RFC 3168).  Every time the
receiver sees a loss, it should signal congestion to the sender, even if
the receiver successfully recovers the data from the redundancy coding. 
As noted above, please just use the ECN signaling support in TCP, don't
try to reinvent it.

> belongs to the explicit solution.

Actually, ECN can't do that, sorry, see above.

> will works well in the network. Discussions and suggestions will be greatly

This behavior can be expected to impact the network - it will be your
responsibility to demonstrate that this is safe (i.e., the default hypothesis
to start from is that it is unsafe, and show us under what assumptions for what
sort of networks it is save).  Among other things, this looks like it could
worsens bufferbloat problems by piling more packets into a congested network
than ordinary TCP would.

Thanks,
--David

> From: wangjinzhu [mailto:[email-masked]]
> Sent: Thursday, February 12, 2015 4:24 AM
> To: Black, David; 'Eggert, Lars'

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 25 Feb 2015 12:54:37 +0000

Hi Jinzhu,

Two points, in addition to David's what are all right spot-on:

> [Jinzhu] I think the work on distinguishing link error loss from
> congestion loss can be classified into explicit solution and
> implicit solution. ECN belongs to the explicit solution. The
> explicit solution requires routers to disclose the network state
> and in some cases may not be easy to be deployed since some
> routers may not enable ECN. Thus if the implicit solution can be
> applied to the coded TCP, it will be easier to be deployed. I’m
> not sure whether there is a method that can distinguish link
> error loss from congestion loss without the feedback from the
> network. Suggestions on the implicit solution will be greatly
> appreciated. 

As David tried to point out, and I will make this more explicit: The TCP part of the ECN feedback mechanism, as it exists since RFC3168, can be used completely without any support by the network routers.

Obviously, in such an environment, the receiver will never actually get any CE-marked IP Packets, which it would have to signal back to the sender, but in your case, the loss, and successful reconstruction of a packet would constitute just as much - thus the RFC3168 section on TCP is fully applicable.

(Recent ECN testing has shown that end-hosts often support ECN in the TCP layer, but paths more often have issues dealing with the IP-layer signals - masking the IP ECN codepoints, setting them inappropriately, etc).

As a side-note, you may want to participate in the TCPM WG discussions on accureate ECN feedback. It's been found that a single feedback signal per RTT is not enough information, for more attenuated responses. In your case, think of an encoding scheme (Reed-Solomon, Low-density parity-check, diagonal parity, ...) that could recover more than a single segment of the encoded packets, or that one RTT actually covers a multitude of encoded groups of packets. Potentially, you want to give a differentiated feedback signal on the extent of that loss - not for TCP congestion control purposes alone, but also for example for your encoder. A less lossy network could do with larger groups of encoded packets, while with a more lossy network, you'd probably want to increase the encoding ratio...

The second observation I want to point out is that this work seems quite similar to 

TCP Instant Recovery: Incorporating Forward Error Correction in TCP Tobias Flach, USC, N. Dukkipati, Y. Cheng, B. Raghavan, Google
http://tools.ietf.org/html/draft-flach-tcpm-fec-00

which actually also looked into secondary problems like stateful firewall traversal, backwards-compliant encoding of the parity packets, etc. 

and, of course, the work on Coded TCP by Muriel Médard et.al.
http://www.ietf.org/proceedings/87/slides/slides-87-nwcrg-4.pdf

As David and Lars pointed out, you will have to be very careful NOT to inadvertently conceal congestion loss from the sender. You may want to collaborate with these groups...

Best regards,
  Richard

> From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
> Sent: Freitag, 13. Februar 2015 00:50
> To: wangjinzhu; Eggert, Lars
> > >+1 - the baseline approach should be ECN-like behavior where the
> > >+recovered
> > data is delivered, but the loss is communicated to the sender in order
> > to cause the sender's congestion control logic to react (ECN treats a
> > CE-marked packet as if it were dropped). I would suggest using at
> > least the ECN signaling, even if the packets aren't marked as using
> > ECN, as  ECN has the receiver-to-sender signaling worked out (i.e.,
> > please don't try to reinvent that).
> >
> > [Jinzhu] Thanks, this suggestion is important to coded TCP. By using
> > ECN, the network congestion can be explicitly notified and the sender
> > can adjust congestion window timely when congestion occurs. I will
> > work on it and further update the draft to combine coded TCP with ECN.
> 
> When ECN is used, drops may still indicate congestion (i.e., use of ECN
> does not result in all drops being due to link errors or the like and
> never due to congestion).  There are at least two reasons for this:
> 
> > [Jinzhu] I think the work on distinguishing link error loss from
> > congestion loss can be classified into explicit solution and implicit
> > solution. ECN belongs to the explicit solution.
> 
> > congestion by another way, though this behavior is different to
> > current Internet congestion control. For example, we set the
> > redundancy as 10% in the coded TCP. In the standard TCP, when the
> > network bottleneck utilization achieves to 100%, the TCP sender
> > reduces sending rate to response the congestion (this is just a simple
> illustration, the 100% is inaccurate).
> > While in the coded TCP, when the bottleneck utilization achieves to a
> > higher value (perhaps 110%), the redundancy cannot recover loss and
> > thus the coded TCP sender reduces the sending rate to control Internet
> congestion.
> > Currently, I’m not sure whether this behavior will impact the network
> > or it will works well in the network. Discussions and suggestions will
> > be greatly appreciated
> 
> responsibility to demonstrate that this is safe (i.e., the default
> hypothesis to start from is that it is unsafe, and show us under what
> assumptions for what sort of networks it is save).  Among other things,
> this looks like it could worsens bufferbloat problems by piling more
> packets into a congested network than ordinary TCP would.
> 
> Thanks,
> --David
> 
> 
> > >+1 - the baseline approach should be ECN-like behavior where the
> > >+recovered
> > data is delivered, but the loss is communicated to the sender in order
> > to cause the sender's congestion control logic to react (ECN treats a
> > CE-marked packet as if it were dropped). I would suggest using at
> > least the ECN signaling, even if the packets aren't marked as using
> > ECN, as  ECN has the receiver-to-sender signaling worked out (i.e.,
> > please don't try to reinvent that).
> >
> > [Jinzhu] Thanks, this suggestion is important to coded TCP. By using
> > ECN, the network congestion can be explicitly notified and the sender
> > can adjust congestion window timely when congestion occurs. I will
> > work on it and further update the draft to combine coded TCP with ECN.
> >
> > deployment in an environment that exhibits high non-congestive losses,
> > as described in the Introduction:
> > >
> > recoverable loss (and with good choice of coding algorithm, most of
> > them will be) as not indicating congestion.  As Lars notes, that's not
> > acceptable because it fails to react to recovered losses that do
> > actually indicate congestion.
> > >
> > >caused
> > by congestion vs. link errors, but I can't quickly provide any
> > [Jinzhu] Yes, we are trying to recover link error loss at the receiver
> > side by using redundancy coding. However, since the coded TCP sender
> > cannot distinguish wireless link error loss from congestion loss, it
> > treat the link error loss the same as the congestion loss.
> >
> > [Jinzhu] I think the work on distinguishing link error loss from
> > congestion loss can be classified into explicit solution and implicit
> > solution. ECN belongs to the explicit solution. The explicit solution
> > requires routers to disclose the network state and in some cases may
> > not be easy to be deployed since some routers may not enable ECN. Thus
> > if the implicit solution can be applied to the coded TCP, it will be
> > easier to be deployed. I’m not sure whether there is a method that can
> > distinguish link error loss from congestion loss without the feedback
> > from the network. Suggestions on the implicit solution will be greatly
> appreciated.
> >
> > congestion by another way, though this behavior is different to
> > current Internet congestion control. For example, we set the
> > redundancy as 10% in the coded TCP. In the standard TCP, when the
> > network bottleneck utilization achieves to 100%, the TCP sender
> > reduces sending rate to response the congestion (this is just a simple
> illustration, the 100% is inaccurate).
> > While in the coded TCP, when the bottleneck utilization achieves to a
> > higher value (perhaps 110%), the redundancy cannot recover loss and
> > thus the coded TCP sender reduces the sending rate to control Internet
> congestion.
> > Currently, I’m not sure whether this behavior will impact the network
> > or it will works well in the network. Discussions and suggestions will
> > be greatly appreciated
> >
> >
> > >Thanks,
> > >--David
> >
> > > >recover the loss by using redundancy (packet loss is low), the
> > > >sender side does not see the packet loss and thus keep on
> > > >increasing congestion
> > window.
> > >>