Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 21 Oct 2013 21:43:14 +0200

Hi Bob,

just quickly; we submitted a new version. We adopted most of your proposals. 
We didn't change the name though, as there is currently no really good 
proposal and we don't want to change this over and over again. If the working 
group decides for one term, we are happy to change it everywhere in the 
document.

See one more comment below.

On Wednesday 14 August 2013 00:31:56 Bob Briscoe wrote:
> Richard, Mirja,
>
> As promised, my detailed review of draft-ietf-tcpm-accecn-reqs-03 is here:
> <http://bobbriscoe.net/projects/2020comms/accecn/>
>
> I have written my suggested changes as mods to the XML source of the
> draft merely for convenience. Pls feel free to copy & paste from my
> XML, to accept or reject each change. I have provided a diff against
> the original draft-03, which will be the best way to read the suggestions.
>
> Most of the changes are editorial - you've often tended to use a
> German-like sentence structure. It's understandable to an English
> eye, but it doesn't really flow in English. In a number of places,
> I've also tried to explain what I think you were meaning a little better.
>
> Superficially it looks like a total re-write, but it's not really.
> Unfortunately, the large number of editorial suggestions have caused
> the more significant (e.g. technical) changes to become swamped. So I
> have tried to list the main changes I have suggested here:
>
> * Suggested 'fine-grained' would be a better term than 'more
> accurate' throughout.
> * Suggested to add paras introducing ConEx & DCTCP to the Intro
> * Suggested adding more motivation to Intro, esp interoperation
> between DCTCP implementations.
> * Suggested adding explanation of why it's not so bad to re-use the
> nonce bits (in IP & TCP headers)
> * Suggested shifting certain requirement sentences that I thought
> were not under the most appropriate requirement bullet
> * Suggested adding more specific requirements relating to delayed acks
> * Suggested adding requirements on backward & forward compatibility
> (including shifting some sentences that were under other headings
> into this one).
>
> __________________
> Finally, there were a couple of sentences I thought were incorrect,
> so I suggested deleting or altering them. If you intended them to be
> this way, pls explain:
>
> "While classic ECN provides a reliable (inaccurate) feedback of a
> maximum of one congestion signal per RTT, the proposed schemes do not
> implement any acknowledgement mechanism." [They do.]
I kept the sentence (adding an 'explicit'; see draft). We meant that there is 
no mechanism where the sender actually tells the receiver that it has 
received the feedback signal... you are saying 'they do'; if so, can you 
explain?

Mirja

>
> "Providing wrong feedback information could otherwise lead to
> throttling of certain connections." [I would have thought certain
> connections would go faster than intended, not be throttled?]
>
>
> Bob
>
> At 08:15 07/08/2013, Michael Welzl wrote:
> >Hi all,
> >
> >I second what Bob says below. Let's avoid having various proprietary
> >signaling methods for the same thing deployed and instead
> >standardize a single one.
> >
> >Cheers,
> >Michael (W)
> >
> >On 6. aug. 2013, at 17:26, Bob Briscoe wrote:
> > > Michael,
> > >
> > > I plan to do this in the next few days.
> > > I will produce a rev of the xml, so the authors can use any text
> >
> > directly (or not).
> >
> > > The main things I plan to add, other than editorial stuff, is to
> >
> > motivate standardisation for interoperation:
> > > * Although DCTCP was presented at the IETF, a protocol spec has
> >
> > not being offered for standardisation so far
> >
> > > * DCTCP is becoming widely deployed and it uses a non-standard
> >
> > TCP wire protocol for feedback
> >
> > > * The way the Windows 8 DCTCP negotiates use of this non-standard
> >
> > TCP feedback protocol is proprietary and unspecified
> >
> > > * We do not want widespread deployment of a proprietary TCP
> >
> > feedback negotiation protocol to burn up the few remaining flags or
> > options so that de facto they become unavailable for use in standards.
> >
> > > * The feedback protocol used in the Windows 8 DCTCP assumes no
> >
> > losses and quickly gets very confused about ECN feedback if there
> > are losses as well
> >
> > > * Other implementations of DCTCP (Linux, FreeBSD) seem to be
> >
> > inventing their own different feedback protocols
> >
> > > * These different wire protocols have not been specified to
> >
> > interwork with each other - they all seem to assume that the other
> > end is using the same implementation
> >
> > > However, I want to properly investigate the ground truth under as
> >
> > many of these statements as I can first (I've done most of them).
> >
> > > Bob
> > >
> > > At 15:40 06/08/2013, Scharf, Michael (Michael) wrote:
> > >> Hi all,
> > >>
> > >> According to our minutes, you volunteered in the TCPM meeting to
> >
> > review draft-ietf-tcpm-accecn-reqs-02. The TCPM chairs appreciate
> > this a lot, since this document didn't get a lot of feedback recently.
> >
> > >> It would really help if you could have a look at the document
> >
> > and post your thoughts to the TCPM mailing list. We are
> > specifically interested whether the problem statement and the
> > requirements are complete. It would also be of interest if the
> > survey of the design approaches misses something.
> >
> > >> Again, thanks a lot for volunteering!
> > >>
> > >> Michael
> > >
> > > ________________________________________________________________
> > > Bob Briscoe,                                                  BT
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Oct 2013 21:52:30 +0100

Mirja,

>group decides for one term, we are happy to change it everywhere in the

OK. Thx.

>received the feedback signal... you are saying 'they do'; if so, can you

I meant that, by repeating the current feedback 
level on every packet, it is reliably 
acknowledged whenever there is not a pure ack.

It is however true that there may not be a hard 
reliable acknowledgement (e.g. per RTT) if all 
the acks in an RTT are pure acks. But there is 
still soft reliability by constant repetition.

Bob

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 22 Oct 2013 12:31:49 +0000

Hi,

as an author I'd like to share my thoughts about the naming.

First, I want to state that I'm not feeling strongly about any particular name (they are all just tags). 

However, I believe the use of the latin leanword "accurate" is good as these kind of words have the same meaning across a range of (European) languages, and signify something special to non-native speakers. Particular if the alternative would be regular English words like full, complete...

But if someone feels strongly about using a different qualifier in these drafts, please say so! 

Having said that, as the new text expanded a number of sections

http://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accecn-reqs-04

we would like to have additional reviews!

Richard Scheffenegger

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Montag, 21. Oktober 2013 21:43
> To: [email-masked]
> Cc: Bob Briscoe; Scheffenegger, Richard
> Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02
> 
> Hi Bob,
> 
> proposal and we don't want to change this over and over again. If the
> working group decides for one term, we are happy to change it everywhere
> in the document.
> 
> > German-like sentence structure. It's understandable to an English eye,
> > but it doesn't really flow in English. In a number of places, I've
> > also tried to explain what I think you were meaning a little better.
> >
> > * Suggested 'fine-grained' would be a better term than 'more accurate'
> > throughout.
> > * Suggested shifting certain requirement sentences that I thought were
> > not under the most appropriate requirement bullet
> > (including shifting some sentences that were under other headings into
> > this one).
> >
> > __________________
> > Finally, there were a couple of sentences I thought were incorrect, so
> > I suggested deleting or altering them. If you intended them to be this
> > way, pls explain:
> >
> I kept the sentence (adding an 'explicit'; see draft). We meant that there
> is no mechanism where the sender actually tells the receiver that it has
> > >signaling methods for the same thing deployed and instead standardize
> > >a single one.
> > >
> > >Cheers,
> > >Michael (W)
> > >
> > > and post your thoughts to the TCPM mailing list. We are specifically
> > > interested whether the problem statement and the requirements are
> > > complete. It would also be of interest if the survey of the design
> > > approaches misses something.
> > >
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: +49(0)711/685-67973