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

[Matthew Ford <[e-mail]>]

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]]
>>> 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