Re: [re-ECN] Expired re-ECN Internet Drafts

[Mirja Kuehlewind <[e-mail]>]

Hi,

I've read both and I definitely agree that the "motivation" document should be 
renamed in something containing the word framework and having a seperat 
shorter motivation document. I also would shorten the introduction a little 
or even restructure it. 

Regarding 1.2)
I don't see the point to distinguish between negative, positive, cautious, 
canceled and neutral; at least not in this part of the document. I think 
positive, negative and neutral would be enough at this point. Then I'm 
missing this little picture you can find in other document 
(draft-briscoe-tsvwg-re-ecn-tcp-07) in 4.1:

         +---------- Feedback-------------+
          |                                              |
          v                                             |
        +---+     +----+     +----+     +---+
        |  S  |--->| Q1  |--->| Q2 |--->|  R  |
        +---+     +----+     +----+     +---+

1.3)
No need to talk here about upstream and downstream congestion. (This will be 
done later in more detail.) The only thing a reader needs to know is if there 
a flow with more negative than positive markings it is called negative. A 
little picture would be nice here as well.

4.2)
  "Source congestion control:  We want to ensure that the sender will
      throttle its rate as downstream congestion increases.  Whatever
      the agreed congestion response (whether TCP-compatible or some
      enhanced QoS), to some extent it will always be against the
      sender's interest to comply."
Not sure if this is correct: If a sender needs a certain rate it might be fair 
to not react on congestion (at one time) as long as the same user is no 
allocating more capacity then needed for other applications (all the other 
time).

Also to 4.2)
Maybe the role of the dropper has to be more defined. There are just points 
described what SHOULD be done. There might be also some hard limits. E.g. the 
max time in which a negative flows should be detected or maybe a min time 
before the dropper should react at all or something completly different might 
be a relevant value but anyway more specific borderlines for implementation 
restrictions are needed here.
Then a more detailed section about what the router MUST and SHOULD do might 
belong into the motivation/framework document (see 5.3 in 
draft-briscoe-tsvwg-re-ecn-tcp-07)


Regarding the other document (draft-briscoe-tsvwg-re-ecn-tcp-07) I could 
provide some more input as I have a own Re-ECN Implementation on the Linux 
2.6.26 TCP/IP stack. I'm using this implementation with the NSC to run some 
simulations. 
I can provide some points which haven't been address up to now to complete 
the specification and also bring in some simulation results if needed. How 
will be the next steps here?

Btw. I found some small errors in the current version which falsify the sense:
4.1)
  "The receiver constantly informs the sender of the current count of
   Positive packets it has seen.  The sender uses this information
   determine how many Positive packets it must send into the network.
   The receiver's aim is to balance the number of bytes that have been
   congestion marked with the number of Positive bytes it has sent."
Should be:
  "The receiver constantly informs the sender of the current count of
   Negative packets it has seen.  The sender uses this information
   determine how many Positive packets it must send into the network.
   The sender's aim is to balance the number of bytes that have been
   congestion marked with the number of Positive bytes it has sent."

In table 6:
Pure ACK should be FNE and not RECT (as described in 6.1.5)

Mirja 


On Tuesday 22 September 2009 11:25:17 [e-mail] wrote:
> Out of interest could people let the list know if they have tried to
> read either of these documents and if so whether they found them
> intelligible or not? In particular I am looking for feedback on the
> protocol document which I suspect has become almost impenetrably dense
> over the past 8 revisions by 4 different people...
>
> If people are struggling it may be worth releasing a lightweight
> overview of the protocol before the BoF for non-experts to have a
> starting point...
>
> Toby
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of [e-mail]
> > Sent: 18 September 2009 13:31
> > To: [e-mail]
> > Subject: [re-ECN] Expired re-ECN Internet Drafts
> >
> > There are 2 Internet Drafts for re-ECN, which have recently expired.
> > These are a description of the protocol:
> > http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-07 and one
> > described as a "motivation" for re-ECN:
>
> http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-motivation-00
>
> > which is actually more of an architecture for re-ECN or a framework
>
> for
>
> > using the protocol.
> >
> > These 2 documents do need a re-write. I would hope that if the BOF
>
> goes
>
> > ahead then members of the community would want to shape these new
> > documents, be they direct replacements or entirely new documents. At
> > the
> > very least we need a draft that properly documents the motivation for
> > congestion awareness.
> >
> > In the meantime the expired drafts can be updated only as a
>
> keep-alive.
>
> > I would like to take the opportunity to re-name the motivation to
> > something more accurate, so propose renaming it to "A Framework for
> > adding Congestion Accountability to TCP/IP".
> >
> > Is there anyone who wants to contribute to new documents? It could be
> > with providing content, editing, scoping, etc.
> >
> > Alan
> >
> > _______________________________________________
> > re-ECN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/re-ecn
>
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn



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

web: www.ikr.uni-stuttgart.de
email: [e-mail]
tel: [phone]
-------------------------------------------------------------------