[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
Woj,
replies in line...
Wojciech Dec (wdec) wrote:
> Hi Stefaan,
>
> Inline...
>
>
>>-----Original Message-----
>>From: Stefaan DE CNODDER
>>[mailto:stefaan.de_cnodder at alcatel-lucent.be]
>>Sent: 10 March 2008 13:49
>>To: Wojciech Dec (wdec)
>>Cc: OOGHE Sven; Maglione Roberta; Francois Le Faucheur
>>(flefauch); ancp at ietf.org; BOCCI Matthew
>>Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
>>
>>
>>
>>Hi Woj,
>>
>>Wojciech Dec (wdec) wrote:
>>
>>
>>>Hi Stefaan,
>>>
>>>the controversies I have been able to find concerned the
>>
>>distinction
>>
>>>between accounting and reporting, which has now been clarified.
>>>However, I would agree that the application of graceful restart is
>>>wider than just mcast flow reporting, and thus can be
>>
>>considered for a
>>
>>>follow on phase.
>>
>>good
>>
>>
>>>Can you point me to the comments/thread that wasn't answered?
>>
>>I do not know if it is really useful to suddenly start
>>discussing a non-WG draft expired long time ago. Anyhow, if
>>the authors would want to plan a new draft, here were the comments:
>>
>>http://www.ietf.org/mail-archive/web/ancp/current/msg00028.html
>>http://www.ietf.org/mail-archive/web/ancp/current/msg00026.html
>
>
> I do not see mcast flow reporting mentioned in the above, but rather
> issues regarding graceful restart.
>
My point is that GR was never discussed at the WG and therefore for the
moment, no extensions have to be defined for GR for the moment.
>
>>I am not sure that replying to these old emails are useful
>>because I must say that I do not remember anymore all the
>>details. Anyhow usefull information for an updated draft.
>>
>>
>>>Regarding the issues of not fitting into a single packet,
>>
>>and/or a lot
>>
>>>of data, these appear to be already addressed with the length and
>>>sub-message number fields in the base GSMP header, besides
>>
>>the use of
>>
>>>TCP.
>>
>>The current ANCP protocol says: "An ANCP implementation
>>SHOULD set the I
>>and subMessage fields to 1 to signify no fragmentation."
>>Clearly, ANCP
>>is not designed for such fragmentation. Now you can say: "Ok
>>lets add the GSMP fragmentation to ANCP as well", but I do
>>not think it is that obvious because in past discussions it
>>was clear that sometimes just new fields are defined for
>>existing GSMP fields (length fields, Transaction ID), and
>>then we also have to think what if there is a lot of data to
>>sent, the TCP session may reach its maximum window and other
>>ANCP messages might get delayed.
>
>
> There is a relatively simple fix to this, as you already indicate. We
> cannot/will not solve TCP issues in ANCP, and it is a natural
> consequence for us today reagirding this transport protocol. Alternative
> transports can be considered for the future, but for the time being TCP
> is the one we have and I see no reason why it cannot handle this usage
> within its known limits.
I never questioned the use of TCP, for me, TCP is just fine.
Coincidentally the bulk update mechanism that
> is currently covered already runs into this TCP issue as well.
I disagree on this one. Obviously, TCP might always be a bottleneck
(which we simply have to accept) but with the active-flow-all it might
become a lot worse. Whether ANCP messages are put in a bulk message or
not, does not change much to the TCP behaviour. But if you add a lot of
packets to be transferred such as with the active-flow-all, then the
data generated by the active-flow-all might take the whole TCP window,
and the other messages are delayed. For GR, this delay is not that
important because a node is recovering from a reset but again: we do not
have to define protocol extensions for GR at this moment.
regards,
Stefaan
As such,
> I still beleive that flow reports are to be covered.
>
> Regards,
> Woj.
>
>
>>regards,
>>Stefaan
>>
>>
>>
>>
>>>Regards,
>>>Woj.
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Stefaan DE CNODDER
>>>>[mailto:stefaan.de_cnodder at alcatel-lucent.be]
>>>>Sent: 10 March 2008 13:19
>>>>To: Wojciech Dec (wdec)
>>>>Cc: OOGHE Sven; Maglione Roberta; Francois Le Faucheur (flefauch);
>>>>ancp at ietf.org; BOCCI Matthew
>>>>Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
>>>>
>>>>
>>>>Woj,
>>>>
>>>>According to me this reporting all is a bit of controversial.
>>>>People say that it is useful for graceful restart while
>>
>>there is no
>>
>>>>draft about graceful restart. I remember a very old draft
>>
>>on it, on
>>
>>>>which I posted comments but never answered. Since there is no
>>>>document about GR, this means that it is also hard to determine if
>>>>with this reporting function covers all cases for gracefull
>>
>>restart.
>>
>>>>I also think it is also not that straitforward to define
>>
>>the protocol
>>
>>>>because a lot of data has to be transferred from AN to NAS and that
>>>>data does not fit in a single packet. So therefore, I
>>
>>would prefer to
>>
>>>>do this rather later than sooner. Why is there such a hurry for it?
>>>>
>>>>regards,
>>>>Stefaan
>>>>
>>>>
>>>>Wojciech Dec (wdec) wrote:
>>>>
>>>>
>>>>>Hi Folks,
>>>>>
>>>>>allow me to assume that we're talking about multicast
>>>>
>>>>reporting and not
>>>>
>>>>
>>>>>accounting (previously the two got often confused), ie the report
>>>>>conveys only a snapshot of the multicast state on the
>>
>>queried node's
>>
>>>>>target, without conveying the flow(s) byte or duration counters.
>>>>>
>>>>>Now, I went back to check where the reporting items
>>>>
>>>>originated from and
>>>>
>>>>
>>>>>found the following sources/references:
>>>>>A. Reporting was listed/proposed way back at IETF 68
>>>>>(http://www.ietf.org/proceedings/07mar/slides/ancp-4/sld7.htm)
>>>>>B. It is listed as an ANCP open item regarding WT-147
>>>>
>>>>(WT147 contains at
>>>>
>>>>
>>>>>least two mcast reporting requirements) C. Reporting was
>>
>>discussed in
>>
>>>>>Vancouver under the ANCP
>>>>
>>>>Multicast Update
>>>>
>>>>
>>>>>item, and a specific proposal was put forward to include
>>>>
>>>>relevant text.
>>>>
>>>>
>>>>>D. Reporting was cited to be useful for graceful restart
>>
>>(minuted in
>>
>>>>>Vancouver, but this context was also in the graceful restart draft)
>>>>>
>>>>>More specifically reporting was defined/proposed to be at 3
>>>>
>>>>levels of
>>>>
>>>>
>>>>>granularity:
>>>>>1) Report per port
>>>>>2) Report per flow (across AN)
>>>>>3) Global AN multicast flow & port Report
>>>>>
>>>>>The Vancouver minutes contain no firm conclusion on any of
>>>>
>>>>the above,
>>>>
>>>>
>>>>>but do indicate that the discussion was muddled up other
>>
>>tangential
>>
>>>>>topics to this one (lists, accounting, etc). It is my
>>>>
>>>>impression that
>>>>
>>>>
>>>>>with the clarification that reporting is NOT accounting, NOR is it
>>>>>anything to do with lists, the functionality is fairly
>>>>
>>>>straight forward
>>>>
>>>>
>>>>>and has a fair bit of support.
>>>>>
>>>>>Given the above, besides the facts that it appears fairly
>>>>>uncontroversial, that the design team already made inroads
>>>>
>>>>into this,
>>>>
>>>>
>>>>>and that it has been on the table for a good deal of time,
>>>>
>>>>I would say
>>>>
>>>>
>>>>>that reporting is a fair topic to be addressed by the WG
>>>>
>>>>sooner rather
>>>>
>>>>
>>>>>than later, and in the current framework document (a
>>>>
>>>>specific proposal
>>>>
>>>>
>>>>>appears to exist, but likely needs some editorial work).
>>>>>
>>>>>Regards,
>>>>>Woj.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: ancp-bounces at ietf.org
>>
>>[mailto:ancp-bounces at ietf.org] On Behalf
>>
>>>>>>Of OOGHE Sven
>>>>>>Sent: 07 March 2008 05:18
>>>>>>To: Maglione Roberta; Francois Le Faucheur (flefauch);
>>>>>>ancp at ietf.org; Wojciech Dec (wdec); BOCCI Matthew
>>>>>>Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
>>>>>>
>>>>>>Hi Roberta,
>>>>>>
>>>>>>Thanks for bringing this up. The latest version of the framework
>>>>>>draft tries to capture all agreements reached since the Vancouver
>>>>>>meeting. In doing so, I had to rely on the meeting
>>
>>minutes posted on
>>
>>>>>>http://www.ietf.org/proceedings/07dec/minutes/ancp.txt. In those
>>>>>>minutes, I couldn't find clear statements on this topic.
>>
>>Also in the
>>
>>>>>>discussions on the mailing list, I haven't seen a clear
>>
>>conclusion.
>>
>>>>>>That's why I wasn't able to describe reporting mechanisms in the
>>>>>>update.
>>>>>>
>>>>>>Related to this, the chairs indicated in
>>>>>>http://www.ietf.org/mail-archive/web/ancp/current/msg00479.htm
>>>>>
>>>>>l that the scope of the framework and protocol work would
>>>>
>>>>be > somewhat
>>>>
>>>>
>>>>>constrained in order to avoid further delay. I
>>>>>
>>>>>
>>>>>
>>>>>>considered that the reporting capabilities would be part
>>
>>of the WG
>>
>>>>>>decision to re-charter or add new milestones for protocol
>>>>>>extensions.
>>>>>>
>>>>>>So perhaps at this point I would like to ask the chairs
>>
>>for guidance
>>
>>>>>>on this topic.
>>>>>>
>>>>>>Regards,
>>>>>>Sven
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Maglione Roberta [mailto:roberta.maglione at telecomitalia.it]
>>>>>>Sent: donderdag 6 maart 2008 23:39
>>>>>>To: Francois Le Faucheur IMAP; OOGHE Sven; ancp at ietf.org
>>>>>>Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
>>>>>>
>>>>>>Hi Sven,
>>>>>> during Vancouver meeting we discussed about adding in
>>
>>the framework
>>
>>>>>>draft a new use case describing the Reporting capability; during
>>>>>>the meeting no particular concerns or objections on the reporting
>>>>>>functionality itself were raised, the only comment I received was
>>>>>>related to one of the possible reporting method proposed
>>
>>("AN global
>>
>>>>>>Report-Query") My understanding from the meeting was that the
>>>>>>proposed use case had been accepted in principle by the working
>>>>>>group together with the "Port Report-Query" and "Multicast Flow
>>>>>>Report-Query" proposed methods. Looking at the latest
>>
>>version of the
>>
>>>>>>framework draft I saw that the reporting capability has not been
>>>>>>added thus I was wondering if you see any problem in
>>
>>inserting this
>>
>>>>>>use case in the framework draft.
>>>>>>Please let me know.
>>>>>>
>>>>>>Thanks and best regards
>>>>>>Roberta
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: ancp-bounces at ietf.org on behalf of Francois Le Faucheur IMAP
>>>>>>Sent: Wed 3/5/2008 10:30 AM
>>>>>>To: OOGHE Sven; ancp at ietf.org
>>>>>>Subject: [ANCP] Comments on draft-ietf-ancp-framework-05.txt
>>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>Please find below a few comments/suggestions on framework-05.
>>>>>>
>>>>>>Francois
>>>>>>
>>>>>>
>>>>>>* under section 3.4.2: first bullet.
>>>>>>The following text has been added:
>>>>>> "The NAS may locally maintain available "video"
>>>>>> bandwidth on the Access Loop, and perform video bandwidth
>>>>>> accounting for the Access Loop. Upon receiving an Admission
>>>>>> Request from the AN, the NAS can check available "video"
>>>>>>bandwidth
>>>>>> before admitting or denying the multicast flow. In the
>>>>>>process,
>>>>>> the NAS may communicate with the Policy Server.
>>
>>For unicast
>>
>>>>>>video
>>>>>> services such as Video on Demand (VoD), the Policy
>>
>>Server may
>>
>>>>>>also
>>>>>> query the NAS, so that it can perform admission
>>>>
>>>>control for the
>>>>
>>>>
>>>>>> unicast flow, and update the available video bandwidth
>>>>>>maintained
>>>>>> by the NAS.
>>>>>>"
>>>>>>Could we make this slightly more generic and replace the last
>>>>>>sentence with something like:
>>>>>>"For unicast video services such as Video on Demand
>>
>>(VoD), the NAS
>>
>>>>>>may also be queried (by a Policy Server or via on-path CAC
>>>>>>signaling), so that it can perform admission control for
>>
>>the unicast
>>
>>>>>>flow, and update the available video bandwidth maintained by the
>>>>>>NAS."
>>>>>>
>>>>>>* section 3.4.2: 2nd bullet.
>>>>>>Similarly could we replace:
>>>>>>"For unicast video services the policy server may query
>>
>>the NAS to
>>
>>>>>>perform admission control for the unicast flow, and update the
>>>>>>available video bandwidth maintained by the NAS."
>>>>>>by
>>>>>>"For unicast video services the NAS may be queried (by a policy
>>>>>>server or via on-path CAC signaling) to perform admission control
>>>>>>for the unicast flow, and update the available video bandwidth
>>>>>>maintained by the NAS."
>>>>>>
>>>>>>
>>>>>>* section 4.7.6
>>>>>>The last requirement in the section is intended to reflect the
>>>>>>"Spontaneous Admission Response" functionality described
>>
>>in section
>>
>>>>>>3.4.4.
>>>>>>As agreed, one scenario has been added to section 3.4.4 (ie where
>>>>>>the NAS is made aware of Join/Leave by other means than
>>
>>ANCP), and
>>
>>>>>>this scenario needs to be reflected in section 4.7.6. I'd suggest
>>>>>>adding something like:
>>>>>>" o Upon receiving an Admission Response from the NAS
>>>>
>>>>indicating
>>>>
>>>>
>>>>>>that replication of a multicast flow is to start or stop
>>
>>on a given
>>
>>>>>>access port of the AN, the AN must enforce this decision
>>
>>whether a
>>
>>>>>>corresponding Admission Request was issued earlier by the
>>
>>AN or not.
>>
>>>>>>"
>>>>>>
>>>>>>* section 4.7.6:
>>>>>>replace:
>>>>>>"the AN should support receiving ANCP messages from the NAS
>>>>>>containing conditional access information of multiple
>>>>
>>>>multicast flows"
>>>>
>>>>
>>>>>>by
>>>>>>"the AN should support receiving ANCP messages from the NAS
>>>>>>containing conditional/admission access information of multiple
>>>>>>multicast flows"
>>>>>>
>>>>>>* section 4.7.6
>>>>>>There is one requirement stating that "the AN should support
>>>>>>receiving ANCP messages from the NAS containing
>>
>>conditional access
>>
>>>>>>information of multiple multicast flows."
>>>>>>The details of such mechanism is largely left to the
>>
>>protocol design
>>
>>>>>>team, which is fine.
>>>>>>But it may be useful to identify one additional associated
>>>>>>requirement on AN, allowing AN to tell NAS that there is
>>
>>no longer
>>
>>>>>>any multicast flows joined (within the admitted set of
>>>>>>flows) so the corresponding bandwidth can be freed up
>>
>>(where CAC is
>>
>>>>>>performed).
>>>>>>This could read :
>>>>>>" o after receiving ANCP messages from the NAS containing
>>>>>>conditional access information of a set of multicast
>>
>>flows, the AN
>>
>>>>>>should support using ANCP to notify the NAS when there is
>>
>>no longer
>>
>>>>>>any multicast flows from that set joined for a
>>
>>configurable time-out
>>
>>>>>>period."
>>>>>>
>>>>>>
>>>>>>*section 4.8.6:
>>>>>>replace:
>>>>>>"the NAS should support sending an Admission Response message
>>>>>>containing conditional access information of multiple
>>>>
>>>>multicast flows"
>>>>
>>>>
>>>>>>by
>>>>>>"the NAS should support sending an Admission Response message
>>>>>>containing conditional/admission access information of multiple
>>>>>>multicast flows"
>>>>>>
>>>>>>
>>>>>>* section 4.8.6:
>>>>>>there needs to be a requirement here also for spontaneous
>>
>>admission
>>
>>>>>>response. I would propose:
>>>>>>" o the NAS may support using ANCP to indicate to the AN that
>>>>>>replication of a multicast flow is to start or stop on a given
>>>>>>access port of the AN, without having received a corresponding
>>>>>>Admission Request earlier from the AN.
>>>>>>"
>>>>>>
>>>>>>*section 4.8.6
>>>>>>I believe the WG agreed that the following text needs to be
>>>>>>confirmed on the list before it could stay in framework doc.
>>>>>>"
>>>>>> o The ANCP MUST allow the NAS, when replying to an AN
>>>>
>>>>request, to
>>>>
>>>>
>>>>>> OPTIONALLY convey information on multiple multicast flows
>>>>>>sharing
>>>>>> the same conditional access rules. This allows the
>>>>
>>>>AN to take
>>>>
>>>>
>>>>>> autonomous decisions for these flows later on.
>>>>>>"
>>>>>>
>>>>>>
>>>>>>editorial suggestions:
>>>>>>================
>>>>>>* Section 3.4:
>>>>>>Current text:
>>>>>>"The NAS can perform conditional
>>>>>> access and multicast admission control on IGMP joins,
>>
>>and create
>>
>>>>>> replication state in the AN if the flow is admitted by
>>
>>the NAS."
>>
>>>>>>Change:
>>>>>>replace "IGMP joins" by "joins"
>>>>>>Justification:
>>>>>>Joins/leaves may be communicated via IGMP or via some other means.
>>>>>>
>>>>>>* section 3.4.2.2
>>>>>>replace:
>>>>>>"Otherwise, the Access Node would have to query the NAS for
>>>>>>Multicast Admission Control"
>>>>>>by:
>>>>>>"Otherwise, the Access Node would have to query the NAS for
>>>>>>Multicast Admission Control (as per Grey List behavior)"
>>>>>>
>>>>>>
>>>>>>Typos:
>>>>>>=====
>>>>>>* section 3.4.2:
>>>>>>s/as well as for other a set of multicast flows/as well
>>
>>as for a set
>>
>>>>>>of multicast flows/
>>>>>>* in a few places: replace "lateron" by "later on"
>>>>>>_______________________________________________
>>>>>>ANCP mailing list
>>>>>>ANCP at ietf.org
>>>>>>https://www.ietf.org/mailman/listinfo/ancp
>>>>>>
>>>>>>----------------------------------------------------------
>>
>>----------
>>
>>>>>>CONFIDENTIALITY NOTICE
>>>>>>
>>>>>>This message and its attachments are addressed solely to
>>
>>the persons
>>
>>>>>>above and may contain confidential information. If you
>>
>>have received
>>
>>>>>>the message in error, be informed that any use of the
>>
>>content hereof
>>
>>>>>>is prohibited. Please return it immediately to the sender
>>
>>and delete
>>
>>>>>>the message. Should you have any questions, please contact us by
>>>>>>replying to webmaster at telecomitalia.it.
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> www.telecomitalia.it
>>>>>>
>>>>>>----------------------------------------------------------
>>
>>----------
>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>ANCP mailing list
>>>>>>ANCP at ietf.org
>>>>>>https://www.ietf.org/mailman/listinfo/ancp
>>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>ANCP mailing list
>>>>>ANCP at ietf.org
>>>>>https://www.ietf.org/mailman/listinfo/ancp
>>>>
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp