Subject: Re: [Tsv-art] [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Jun 2018 21:14:41 +0200

Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

   ;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> 
> Hi!  How are you?
> 
> Gaurav just posted a revision.  Please take a look and let us know if 
> the changes address your concerns or not.
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-09
> 
> Thanks!!
> 
> Alvaro.
> 
> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ([email-masked] 
> <mailto:[email-masked]>) wrote:
> 
>> Hi Martin,
>>
>> Thanks for review. I will post the new version. Hopefully, it will 
>> address all your comments and we can close this review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>> On May 23, 2018, at 4:17 AM, Gaurav Dawra <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Hi Martin,
>>>
>>> Thanks for the review. Any further comments here ? I will post the 
>>> new version soon.
>>>
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>>> On May 16, 2018, at 7:44 PM, Gaurav Dawra <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Apologies from my end we had few internal authors conversations on 
>>>> the points you have raised.
>>>>
>>>> Please find below my response. I will be happy to discuss further, 
>>>> if needed.
>>>>
>>>> <Gaurav> inline...
>>>>
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <[email-masked] 
>>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>>>> This got lost on my end, sorry for this. The filter just moved 
>>>>> these messages out of my sight... :-/
>>>>>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling 
>>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've reviewed this document as part of the transport area review 
>>>>>>> team's ongoing effort to review key IETF documents. These 
>>>>>>> comments were written primarily for the transport area directors, 
>>>>>>> but are copied to the document's authors for their information 
>>>>>>> and to allow them to address any issues raised. When done at the 
>>>>>>> time of IETF Last Call, the authors should consider this review 
>>>>>>> together with any other last-call comments they receive. Please 
>>>>>>> always CC tsv-art@… if you reply to or forward this review.
>>>>>>>
>>>>>>> Summary:
>>>>>>> This draft has serious issues in Section 7.1, 7.2 and in one part 
>>>>>>> of Section3, described in the review, and needs to be rethought. 
>>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look 
>>>>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well 
>>>>>>> proven funcationality and not even safe to use functionality. 
>>>>>>> Both are some sort discussing that different paths in the network 
>>>>>>> could be used by the end host traffic. This sounds pretty much 
>>>>>>> like the Path Aware Networking Proposed Research Group 
>>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no 
>>>>>>> commonly understand and accepted engineering solution in this space.
>>>>>>>
>>>>>>> Section 7.1:
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed 
>>>>>>> up in recent times and even worse there is no evidence that this 
>>>>>>> is going to work good enough or stable enough under real Internet 
>>>>>>> traffic. Additionally, it is more than unclear how any modern TCP 
>>>>>>> implementation will react to this
>>>>>> [Gaurav] Will get back on this.
>>>>>
>>>>> I will reply to the other email dicussing this.
>>>> <Gaurav> I have replied to other thread.
>>>>>
>>>>>>>
>>>>>>> Section 7.2:
>>>>>>> This section describes an idea without detailing too much about 
>>>>>>> any further aspects. Further it changes the commonly accepted 
>>>>>>> notion of what an end host can do with the network. At best this 
>>>>>>> would require a good definition of what an end host in your 
>>>>>>> setting is, e.g., a highly modified piece of (at least) software 
>>>>>>> that usually not found in OS availble on the market (yet?)
>>>>>>> Further communicating instantaneous path characteristics to a 
>>>>>>> central point is potentially a bad idea, as the data is already 
>>>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which 
>>>>>> is defined in 
>>>>>> (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15) 
>>>>>> can influence the traffic based on the Calculations locally or 
>>>>>> jointly with the controller. Implementations can decide how much 
>>>>>> Centralized -vs- localized control is allowed at Host based on 
>>>>>> performance data collection.
>>>>>
>>>>> Performance data collection (monitoring?) isn't crucial when it 
>>>>> comes to timely (actually real-time) reaction. However, this 
>>>>> section isn't just about performance data collection as it is about 
>>>>> "Performance-aware routing" this seems to try to interact in 
>>>>> real-time with the network behavior of TCP. This isn't even close 
>>>>> to acceptable.
>>>>>
>>>>> I would be ok to say that it is useful to collect performance data 
>>>>> for offline analysis and improvement of the data network. However, 
>>>>> this is at completely different magnitues of time scales.
>>>>>
>>>>> I would recommend to remove the TCP part from this section entirely.
>>>> <Gaurav>Ack, will update in next rev:
>>>>
>>>> Section will read like this:
>>>>
>>>> ;
>>>> /Knowing the path associated with flows/packets, the end host may/
>>>> /deduce certain characteristics of the path on its own, and/
>>>> /additionally use the information supplied with path information/
>>>> /pushed from the controller or received via pull request. The host/
>>>> /may further share its path observations with the centralized agent,/
>>>> /so that the latter may keep up-to-date network health map to assist/
>>>> /other hosts with this information./
>>>> //
>>>> /For example, an application A.1 at HostA may pin a flow destined/
>>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/
>>>> /application A.1 may collect information on packet loss, deduced from/
>>>> /Other offline mechanisms. [There are some pingMesh mechanisms which /
>>>> /Can be used here]/
>>>> /Through these mechanisms information to a centralized agent, e.g./
>>>> /after a flow completes, or periodically for longer lived flows./
>>>> /Next, using both local and/or global performance data, application/
>>>> /A.1 as well as other applications sharing the same resources in the/
>>>> /DC fabric may pick up the best path for the new flow, or update an/
>>>> /existing path (e.g.: when informed of congestion on an existing/
>>>> /path)./
>>>> ;
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> Section 3, 3rd bullet point:
>>>>>>> It is the foundation of TCP that the network is regarded as a 
>>>>>>> black box and that you infer from the transmission of packets 
>>>>>>> what the current state of the network path is. Inferring network 
>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as 
>>>>>>> this would required that all paths exhibit this and if not what 
>>>>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points 
>>>>>>> in TCP's behavior, but this once again points to the fact that 
>>>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly 
>>>>>> treating Network as Black Box. Authors are implying per path 
>>>>>> performance metrics as not cached. Is there some change in text 
>>>>>> you are suggesting?
>>>>>
>>>>>
>>>>> I would recommend to remove the 3rd bullet point completey. TCP 
>>>>> isn't the place to remember "good" or "bad" paths. This is 
>>>>> something the network could decide, e.g., rerouting TCP flows 
>>>>> within the network or changing the forwarding path in the network 
>>>>> for particular flows (if it is not routed).
>>>>
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd 
>>>> bullet point. Will update in next rev - coming shortly.
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>  Martin
>>>>>
>>>>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 7 Jun 2018 09:02:26 -0700

Thanks Martin!

On June 6, 2018 at 3:14:45 PM, Martin Stiemerling ([email-masked])
wrote:

Hi Alvaro, all,

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!  How are you?
> br/>> Gaurav just posted a revision.  Please takke a look and let us know
if br/>> the changes address your concerrns or not.
> br/>>
https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (([email-masked]
br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
br/>>> address all your comments and we can close thhis review.
>> On May 23, 2018, at 4:17 AM, Gaurav Dawra <[email-masked] br/>>>
>>> Thanks for the review. Any further comments here ? I will post the
br/>>>> new version soon. <
>>>> Apologies from my end we had few internal authors conversations on
br/>>>>> the points you have raised. <
>>>> Please find below my response. I will be happy to discuss further,
br/>>>>> if needed. <
>>>>> This got lost on my end, sorry for this. The filter just moved
br/>>>>>> these messages out of my sight... :-/
>>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>>
<mls.ietf@@gmail.com <mailto:[email-masked]> br/>>>>>>>>; <mailto:
>>>>>>> I've reviewed this document as part of the transport area review
br/>>>>>>>> team's ongoing effort to review key IETF documents. These
br/>>>&gtt;>>>> comments were written primarily for the transport area
directors, br/>>>>>>>> but are copied to the doocument's authors for their
information br/>>>>>>>&> and to allow them to address any issues raised.
When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review
br/>>>>>>>> together with any other last-call comments they receive. Please
br/>>>&>>>>> always CC tsv-art@… if you reply to or forward this review.
>>>>>>> This draft has serious issues in Section 7.1, 7.2 and in one part
br/>>>>>>>> of Secction3, described in the review, and needs to be
rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well
br/>>>>>>>> proven funcationality and not even safe to use functionality.
br/>>>&>>>>> Both are some sort discussing that different paths in the
network br/>>>>>>>> could be used by the eend host traffic. This sounds
pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed
Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the
fact that there is no br/>>>>>>>> commonly understannd and accepted
engineering solution in this space.
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed
br/>>>>>>>> up iin recent times and even worse there is no evidence that
this br/>&gtt;>>>>>> is going to work good enough or stable enough under
real Internet br/>>>>>>>> traffic. Additioonally, it is more than unclear
how any modern TCP br/>>>>&ggt;>>> implementation will react to this
>>>>>>> This section describes an idea without detailing too much about
br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted
br/>>>;>>>>> notion of what an end host can do with the network. At best
this br/>>>>>>>> would require a good ddefinition of what an end host in
your br/>>>>>>>&ggt; setting is, e.g., a highly modified piece of (at
least) software
>>>>>>> Further communicating instantaneous path characteristics to a
br/>>>>>>>> central point is potentially a bad idea, as the data is already
br/>>>;>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which
br/>>>>>>> is defineed in br/>>>>>>> (
https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15)
br/>>>>>>> can innfluence the traffic based on the Calculations locally or
br/>>&gtt;>>>> jointly with the controller. Implementations can decide how
much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Host
based on br/>>>>>>> perfoormance data collection.
>>>>> Performance data collection (monitoring?) isn't crucial when it
br/>>>>>> comes to timely (actuaally real-time) reaction. However, this
br/>>>>>> secttion isn't just about performance data collection as it is
about br/>>>>>>> "Performance-aware routing" this seems to try to interact
in br/>>>>>> real-time with the network behhavior of TCP. This isn't even
close br/>>>>>> to acceeptable.
>>>>> I would be ok to say that it is useful to collect performance data
br/>>>>>> for offline analysis and improvement of the data network.
However, br/>>>>>&ggt; this is at completely different magnitues of time
scales.
>>>>>>> It is the foundation of TCP that the network is regarded as a
br/>>>>>>>> black box and that you infer from the transmission of packets
br/>>>>;>>>> what the current state of the network path is. Inferring
network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad
idea, as br/>>>>>>>>; this would required that all paths exhibit this and
if not what br//>>>>>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points
br/>>>>>>>> in TCP'ss behavior, but this once again points to the fact that
br/>>>&>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly
br/>>>>>>> treating Network as Black Box. Authors are implying per path
br/>>>>;>>> performance metrics as not cached. Is there some change in text
br/>>>>>>> you are suggesting??
>>>>> I would recommend to remove the 3rd bullet point completey. TCP
br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is
br/>>>>>> something the network could decide, e.g., rerouting TCP flows
br/>&ggt;>>>> within the network or changing the forwarding path in the
network br/>>>>>> for particular flows (if it is not routed).
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd
br/>>>>> bullet point. Willl update in next rev - coming shortly.

---

From: Gaurav Dawra <[email-masked]>
Date: Tue, 12 Jun 2018 07:06:10 -0700

Hi Mirja,

Friendly Reminder...Could you please also advice if there is anything
further to DISCUSS on this document which was also related to TCP updates
below?

Cheers,

Gaurav

On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <[email-masked]>
wrote:

> > br/>> Gaurav just posted a revision.  Please takke a look and let us
> know if br/>> the changes address your concerrns or not.
> > br/>> https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-
> segment-routing-msdc-09
> > br/>> Thanks!!!
> > br/>> Alvaro. <
> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((
> [email-masked] br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> > br/>>> Hi Martin, <
> >>
> br/>>> <mailto:gdawra.ietf@@gmail.com>> wrote:
> >>
> >>> Hi Martin,
> >>>
> br/>>>>>>> is defineed in br/>>>>>>> (https://tools.ietf.org/html/
> draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the
> traffic based on the Calculations locally or br/>>&gtt;>>>> jointly with
> the controller. Implementations can decide how much br/>>>>>>> Centralized
> -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance
> data collection.
> >>>>>

---

From: Gaurav Dawra <[email-masked]>
Date: Mon, 18 Jun 2018 17:13:30 -0700

Hi Alvaro, Mirja 

Any feedback or next steps to close this?

Cheers,

Gaurav

Sent from my iPhone

> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> Friendly Reminder...Could you please also advice if there is anything further to DISCUSS on this document which was also related to TCP updates below?
> 
> Cheers,
> 
> Gaurav
> 
>> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <[email-masked]> wrote:
>> Thanks Martin!
>> 
>>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling ([email-masked]) wrote:
>>> 
>>> Hi Alvaro, all, 
>>> 
>>> > br/>> Gaurav just posted a revision.  Please takke a look and let us know if br/>> the changes address your concerrns or not. 
>>> > br/>> https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09 
>>> > br/>> Thanks!!! 
>>> > br/>> Alvaro. < 
>>> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (([email-masked] br/>> <mailto:gdawra.ietf@@gmail.com>) wrote: 
>>> > br/>>> Hi Martin, < 
>>> >> 
>>> >> Thanks for review. I will post the new version. Hopefully, it will br/>>> address all your comments and we can close thhis review. 
>>> >> 
>>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra <[email-masked] br/>>> <mailto:gdawra.ietf@@gmail.com>> wrote: 
>>> >> 
>>> >>> Hi Martin, 
>>> >>> 
>>> >>> Thanks for the review. Any further comments here ? I will post the br/>>>> new version soon. < 
>>> >>> 
>>> >>> Cheers, 
>>> >>> 
>>> >>> Gaurav 
>>> >>> 
>>> >>> Sent from my iPhone 
>>> >>> 
>>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra <[email-masked] br/>>>> <mailto:gdawra.ietf@@gmail.com>> wrote: 
>>> >>> 
>>> >>>> Hi Martin, 
>>> >>>> 
>>> >>>> Apologies from my end we had few internal authors conversations on br/>>>>> the points you have raised. < 
>>> >>>> 
>>> >>>> Please find below my response. I will be happy to discuss further, br/>>>>> if needed. < 
>>> >>>> 
>>> >>>> <Gaurav> inline... 
>>> >>>> 
>>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <[email-masked] br/>>>>>> <mailto:[email-masked]>> wrote: 
>>> >>>>> 
>>> >>>>> Hi Gaurav, 
>>> >>>>> 
>>> >>>>> This got lost on my end, sorry for this. The filter just moved br/>>>>>> these messages out of my sight... :-/ 
>>> >>>>> 
>>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>> <mls.ietf@@gmail.com <mailto:[email-masked]> br/>>>>>>>>; <mailto:[email-masked]>> wrote: 
>>> >>>>>>> 
>>> >>>>>>> Hi all, 
>>> >>>>>>> 
>>> >>>>>>> I've reviewed this document as part of the transport area review br/>>>>>>>> team's ongoing effort to review key IETF documents. These br/>>>&gtt;>>>> comments were written primarily for the transport area directors, br/>>>>>>>> but are copied to the doocument's authors for their information br/>>>>>>>&> and to allow them to address any issues raised. When done at the 
>>> >>>>>>> time of IETF Last Call, the authors should consider this review br/>>>>>>>> together with any other last-call comments they receive. Please br/>>>&>>>>> always CC tsv-art@… if you reply to or forward this review. 
>>> >>>>>>> 
>>> >>>>>>> Summary: 
>>> >>>>>>> This draft has serious issues in Section 7.1, 7.2 and in one part br/>>>>>>>> of Secction3, described in the review, and needs to be rethought. br/>>&>>>>>> The other sections are good AFAIK. 
>>> >>>>>>> 
>>> >>>>>>> 
>>> >>>>>>> Technicals: 
>>> >>>>>>> The overall draft looks ok, but the three points below look br/>>>>>>>> strange and need a fix before publication IMHO: 
>>> >>>>>>> 
>>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>>>>>> proven funcationality and not even safe to use functionality. br/>>>&>>>>> Both are some sort discussing that different paths in the network br/>>>>>>>> could be used by the eend host traffic. This sounds pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no br/>>>>>>>> commonly understannd and accepted engineering solution in this space. 
>>> >>>>>>> 
>>> >>>>>>> Section 7.1: 
>>> >>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>>>>>> up iin recent times and even worse there is no evidence that this br/>&gtt;>>>>>> is going to work good enough or stable enough under real Internet br/>>>>>>>> traffic. Additioonally, it is more than unclear how any modern TCP br/>>>>&ggt;>>> implementation will react to this 
>>> >>>>>>> This section describes an idea without detailing too much about br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted br/>>>;>>>>> notion of what an end host can do with the network. At best this br/>>>>>>>> would require a good ddefinition of what an end host in your br/>>>>>>>&ggt; setting is, e.g., a highly modified piece of (at least) software 
>>> >>>>>>> Further communicating instantaneous path characteristics to a br/>>>>>>>> central point is potentially a bad idea, as the data is already br/>>>;>>>>> outdated when reported by any node. 
>>> >>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>>>>> is defineed in br/>>>>>>> (https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic based on the Calculations locally or br/>>&gtt;>>>> jointly with the controller. Implementations can decide how much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance data collection. 
>>> >>>>> 
>>> >>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>>>> comes to timely (actuaally real-time) reaction. However, this br/>>>>>> secttion isn't just about performance data collection as it is about br/>>>>>>> "Performance-aware routing" this seems to try to interact in br/>>>>>> real-time with the network behhavior of TCP. This isn't even close br/>>>>>> to acceeptable. 
>>> >>>>> 
>>> >>>>> I would be ok to say that it is useful to collect performance data br/>>>>>> for offline analysis and improvement of the data network. However, br/>>>>>&ggt; this is at completely different magnitues of time scales. 
>>> >>>>> 
>>> >>>>>>> It is the foundation of TCP that the network is regarded as a br/>>>>>>>> black box and that you infer from the transmission of packets br/>>>>;>>>> what the current state of the network path is. Inferring network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as br/>>>>>>>>; this would required that all paths exhibit this and if not what br//>>>>>>>> is going to happen? 
>>> >>>>>>> It could be an interesting research field to change many points br/>>>>>>>> in TCP'ss behavior, but this once again points to the fact that br/>>>&>>>>> this not the IETF works but IRTF or elsewhere. 
>>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>>>>> treating Network as Black Box. Authors are implying per path br/>>>>;>>> performance metrics as not cached. Is there some change in text br/>>>>>>> you are suggesting?? 
>>> >>>>> 
>>> >>>>> 
>>> >>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/>&ggt;>>>> within the network or changing the forwarding path in the network br/>>>>>> for particular flows (if it is not routed). 
>>> >>>> 
>>> >>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>>> bullet point. Willl update in next rev - coming shortly. 
>>> >>>> 
>>> >>>>> 
>>> >>>>> Kind regards, 
>>> >>>>> 
>>> >>>>>  Martin 
>>> >>>>> 
>>> >>>> 
>