Re: [re-ECN] preliminary draft of problem statement- authors wanted

[<[e-mail]>]

That is a very good point... and we certainly need to make sure we include a definitions section in this document.

Toby

> -----Original Message-----
> From: Matthew Ford [mailto:[e-mail]]
> Sent: 25 September 2009 10:02
> To: Moncaster,T,Toby,DER3 R
> Cc: [e-mail]; [e-mail]-
> stuttgart.de; [e-mail]
> Subject: Re: [re-ECN] preliminary draft of problem statement- authors
> wanted
> 
> On 25/9/09 09:54, [e-mail] wrote:
> > And here-in lies a serious terminology problem. Downstream and
> upstream are always going to be seen in terms of the precise point of
> measurement. In a BB network we talk about upstream data going TO the
> network because the overwhelming majority of data flows in the other
> direction (DOWN to the user), and because we are talking about overall
> data flows. But when you are looking at individual packets belonging to
> a single flow you have to reverse the terminology...
> >
> > Which makes me wonder if we would be better off talking about it in
> different terms...?
> 
> I'm not sure about this. Terminology is always to some extent
> arbitrary,
> hence the importance of defining terms in the document, so that within
> the confines of the text the meaning is clear.
> 
> Uplink and downlink are the appropriate terms for the broadband end
> site. Upstream and downstream are only meaningful in reference to a
> specific flow.
> 
> (In case it's not clear, I'm saying don't refer to 'upstream' when you
> mean 'uplink')
> 
> Mat
> 
> >
> > Toby
> >
> >> -----Original Message-----
> >> From: Woundy, Richard [mailto:[e-mail]]
> >> Sent: 24 September 2009 18:04
> >> To: Moncaster,T,Toby,DER3 R; [e-mail]
> >> Cc: [e-mail]
> >> Subject: RE: [re-ECN] preliminary draft of problem statement-
> authors
> >> wanted
> >>
> >>> In other words downstream is in the direction of flow and upstream
> is
> >> against the flow. This is based on the conventional usage in English
> >> when referring to real flows e.g. water in rivers...
> >>
> >> I understand this... but in other contexts, ironically, "upstream
> >> congestion" could also refer to congestion on a broadband uplink.
> >> Probably worth including these terms in a "definitions" section in
> the
> >> future. :)
> >>
> >> -- Rich
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of [e-mail]
> >> Sent: Thursday, September 24, 2009 10:43 AM
> >> To: [e-mail]; [e-mail]
> >> Subject: Re: [re-ECN] preliminary draft of problem statement-
> authors
> >> wanted
> >>
> >> Hi Mirja,
> >>
> >> I am in the process of integrating this into the document and
> expanding
> >> it. I have decided to insert some extra bits and am actually
> completely
> >> re-working the whole of section 5 at the same time.
> >>
> >> One thing needs to be clarified (as I have noticed it with other
> people
> >> as well): you seem to have got your terminology back to front. We
> refer
> >> to upstream congestion as being the congestion between a given point
> >> and the origin (source) of the traffic. The downstream congestion is
> >> between that point and the destination (sink) of the traffic. In
> other
> >> words downstream is in the direction of flow and upstream is against
> >> the flow. This is based on the conventional usage in English when
> >> referring to real flows e.g. water in rivers...
> >>
> >> Toby
> >>
> >>> -----Original Message-----
> >>> From: Mirja Kuehlewind [mailto:[e-mail]-
> stuttgart.de]
> >>> Sent: 24 September 2009 12:28
> >>> To: [e-mail]
> >>> Cc: Moncaster,T,Toby,DER3 R
> >>> Subject: Re: [re-ECN] preliminary draft of problem statement-
> authors
> >>> wanted
> >>>
> >>> Hi Toby,
> >>>
> >>> I've tried to fill section 5.3 (see below). I've moved some points
> >> form
> >>> 4.
> >>> (Requirements for a Solution) into this section. So I'm not sure if
> >> 4.
> >>> is
> >>> still an own section. Might be enough to include on paragraph into
> >> the
> >>> introduction.
> >>> I hope this input helps somehow as a starting point for 5.3 or if
> >> this
> >>> is not
> >>> what was meant to be there it may be included in some other part on
> >> the
> >>> document.
> >>>
> >>> Mirja
> >>>
> >>>
> >>> -----------------------------------------
> >>> 5.3.  Re-feedback as a potential solution
> >>>
> >>> To eliminate the asymmetry of information between end-points and
> >>> network
> >>> components it can be supposed to re-insert the congestion feedback
> >>> signaled
> >>> by the receiver into the Internet. Thereby an approximation about
> how
> >>> much
> >>> congestion needs to be expected over the whole path is given.
> Having
> >>> this
> >>> information within the network the congestion policing can be
> >> enforced
> >>> before
> >>> other users get discriminated by "heavy users".
> >>>
> >>> Considering the ECN information as the downstream congestion and
> the
> >>> re-feedbacked congestion information as whole-path congestion, the
> >>> upstream
> >>> congestion (or rest-path congestion) can easily be achieved by
> >>> subtracting
> >>> one form the other. That enables network components to be
> responsive
> >> to
> >>> congestion instead just rely on the end-hosts.
> >>>
> >>> The upstream congestion reveals valuable information at ISP
> borders.
> >> On
> >>> the
> >>> one hand the amount of congestion that will be pushed into a domain
> >> can
> >>> become part of an inter-domain agreement. One the other hand the
> >> amount
> >>> of
> >>> the expected upstream congestion might lead to switch to a less
> >>> congestion
> >>> network-domain (what might boost the competition to provide a more
> >>> reliable
> >>> network).
> >>>
> >>> Summing up, the exposure of downstream, upstream and the whole-path
> >>> congestion
> >>> can be achieved by re-insertion of congestion notifications and
> will
> >>> establish an information symmetry between users and network
> >> providers.
> >>> This
> >>> will open a door for incremental deployment and an evolution to new
> >>> congestion responses which are not bounded anymore to an "universal
> >>> rate
> >>> adaptable policy" as the information equilibrium implicit controls
> a
> >>> fair
> >>> capacity sharing.
> >>>
> >>>
> >>> On Thursday 24 September 2009 10:04:03 [e-mail] wrote:
> >>>> Hi Michael,
> >>>>
> >>>> Thanks for the useful feedback. Clearly this document is still in
> >> its
> >>>> very early stages. I will try and produce a new version by end of
> >> the
> >>>> week  which will hopefully address some of your comments.
> >>>>
> >>>> Meanwhile I am still keen to get volunteers willing to contribute
> >>> chunks
> >>>> of text for any of the sections.
> >>>>
> >>>> Toby
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Michael Menth [mailto:[e-mail]]
> >>>>> Sent: 23 September 2009 22:41
> >>>>> To: Moncaster,T,Toby,DER3 R
> >>>>> Cc: [e-mail]
> >>>>> Subject: Re: [re-ECN] preliminary draft of problem statement-
> >>> authors
> >>>>> wanted
> >>>>>
> >>>>> Hi Toby,
> >>>>>
> >>>>> I read the whole document and still it is unclear in many parts.
> >> I
> >>>>> marked them in the attached doc-file. I hope this helps to
> >> improve
> >>> its
> >>>>> clarity.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>     Michael
> >>>>>
> >>>>> [e-mail] schrieb:
> >>>>>> Hi All,
> >>>>>>
> >>>>>> As promised here is a new draft of the problem statement with a
> >>> bit
> >>>>> more meat on the bones. There is still an awful lot of work to be
> >>> done
> >>>>> on this and not too much time to do it. Our absolute deadline to
> >>> get
> >>>>> something in is October 19th - only just over 3 weeks away...
> >>>>>
> >>>>>> As before I would welcome any contributions of text or general
> >>>>> comments. When I have a bit more time I will do proper xml2rfc
> >>> author
> >>>>> entries for everyone that has contributed... For political
> >> reasons
> >>> I
> >>>>> want it to be clear that this is a document that has been worked
> >> on
> >>>>> from people across the whole range of the IETF community.
> >>>>>
> >>>>>> Toby
> >>>>>>
> >>>>>>
> >>>
> ____________________________________________________________________
> >>>>>> Toby Moncaster, Senior Researcher, Network Infrastructure
> >>> Practise
> >>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]
> >>>> ------------------------------------------------------------------
> -
> >> --
> >>>>> -
> >>>>>
> >>>>>> --
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> re-ECN mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/re-ecn
> >>>>> --
> >>>>> Dr. Michael Menth, Assistant Professor
> >>>>> University of Wuerzburg, Institute of Computer Science Am
> >> Hubland,
> >>> D-
> >>>>> 97074 Wuerzburg, Germany, room B206
> >>>>> phone: [phone] (new), fax: [phone]
> >>>>> mailto:[e-mail]
> >>>>> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>>> _______________________________________________
> >>>> 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]
> >>> -------------------------------------------------------------------
> >> _______________________________________________
> >> 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