Subject: [Speermint] VoIP Use Cases Questions

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Dec 2009 13:09:22 -0500

Hi team,

We got some feedbacks from the IESG for this draft. We want to ask the team
for opinions.

Q1: Should this draft be descriptive or prescriptive? In other words, should
this draft describe what is happening in the real-world or what the WG plans
to see. We think this draft is to capture what is happening in the
real-world.

Q2: Should the SBC reset the Max-Forwards? In our network, the SBC does
reset the Max-Forwards. However, the IESG thinks the SBC should decrement
the Max-Forwards rather than resetting it. This is back to Q1, should this
draft be descriptive or prescriptive.

After we receive comments from the WG, we will update the draft and release
a new revision.

Thanks,
Adam and Yiu

---

From: "Terry Martin" <[email-masked]>
Date: Tue, 1 Dec 2009 14:19:49 -0500

I am not a member of the team writing the draft but I have been monitoring this list for several years because I work with SBC's and VoIP networks and I want to understand how these system can be put together to improve my customers experience.  

>From my perspective it does have to have a descriptive component to outline real world direction vendors are taking.  But it should offer some prescriptive definitions to improve on real world implementation issues. 

As for Max-forwards, all the systems I work with have a limit and it resets.  I believe the reason why it is done this way is to keep memory and process usage to a minumim to keep costs down.

I would like to understand why the IESG thinks the SBC should decrement
the Max-Forwards rather than resetting it.  I would like to understand the benefits for doing decrementing verse resetting.  How will it help my customers?

That is what I am looking for in the draft.

Thank you for allowing me to comment.

Terry Martin
TimeData Corporation
VP of Network Operation
West Coast Number     503-678-2224
Cell:                            503-318-8909

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee, Yiu
Sent: Tuesday, December 01, 2009 10:09 AM
To: [email-masked]
Subject: [Speermint] VoIP Use Cases Questions

Hi team,

Thanks,
Adam and Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Dec 2009 14:40:11 -0500

Hi Terry,

You don't have to be the member of the team to give us comments. We welcome
you for any feedback.

For the Max-Forward question, the IESG believes that the SBC is only a hop
of the call, so it should not reset the Max-Forward. Rather, it should just
decrement the Max-Forward. Other than that, I can't think of any benefit.

Yiu

On 12/1/09 2:19 PM, "Terry Martin" <[email-masked]> wrote:

> I am not a member of the team writing the draft but I have been monitoring
> this list for several years because I work with SBC's and VoIP networks and I
> want to understand how these system can be put together to improve my
> customers experience.
> 
> From my perspective it does have to have a descriptive component to outline
> real world direction vendors are taking.  But it should offer some
> prescriptive definitions to improve on real world implementation issues.
> 
> As for Max-forwards, all the systems I work with have a limit and it resets.
> I believe the reason why it is done this way is to keep memory and process
> usage to a minumim to keep costs down.
> 
> the Max-Forwards rather than resetting it.  I would like to understand the
> benefits for doing decrementing verse resetting.  How will it help my
> customers?
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 1 Dec 2009 21:13:42 +0100

Adam and Yiu,

Your general question about whether the draft is descriptive or prescriptive is a good one.

The draft is currently designated Informational, which would suggest it is descriptive, although Informational RFCs have been published that have a prescriptive content. So the Informational designation perhaps doesn't mean much.

Reading the Introduction section, it certainly isn't clear. The fact that it states "Most of 
        the message diagrams were based on previous work described within 
        existing IETF standards documents."
would suggest that is showing what ought to be done rather than what is typically done in practice.

Whatever the intent, the intent should be made clear in the Introduction section.

However, there has been some discussion about abandoning this work item.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lee, Yiu
> Sent: 01 December 2009 18:09
> To: [email-masked]

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Dec 2009 15:35:44 -0500

Hi John,

It seems you refer to the "draft-ietf-speermint-flows" draft. Our questions
are about the "draft-ietf-speermint-voip-consolidated-usecases"

Thanks,
Yiu

On 12/1/09 3:13 PM, "Elwell, John" <[email-masked]>
wrote:

> The draft is currently designated Informational, which would suggest it is
> descriptive, although Informational RFCs have been published that have a
> prescriptive content. So the Informational designation perhaps doesn't mean
> much.
>

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 1 Dec 2009 16:02:45 -0600

The benefit of not resetting but decrementing relates to the possibility that this peering point is one of a series where other interfaces could lead to possible looping of a call.  Problem is that you can't always guarantee what happens at the next hop.

Mike

> Sent: Tuesday, December 01, 2009 2:40 PM
> To: Terry Martin; [email-masked]
> Subject: Re: [Speermint] VoIP Use Cases Questions
> 
> Hi Terry,
> 
> You don't have to be the member of the team to give us comments. We
> welcome you for any feedback.
> 
> of the call, so it should not reset the Max-Forward. Rather, it should
> just decrement the Max-Forward. Other than that, I can't think of any
> benefit.
> 
> Yiu
> 
> 
> > I am not a member of the team writing the draft but I have been
> > monitoring this list for several years because I work with SBC's and
> > VoIP networks and I want to understand how these system can be put
> > together to improve my customers experience.
> >
> > From my perspective it does have to have a descriptive component to
> > outline real world direction vendors are taking.  But it should offer
> > some prescriptive definitions to improve on real world implementation
> issues.
> >
> > I believe the reason why it is done this way is to keep memory and
> > process usage to a minumim to keep costs down.
> >
> > I would like to understand why the IESG thinks the SBC should
> > decrement the Max-Forwards rather than resetting it.  I would like to
> > understand the benefits for doing decrementing verse resetting.  How
> > will it help my customers?
> >
> > We got some feedbacks from the IESG for this draft. We want to ask the
> > team for opinions.
> >
> > Q1: Should this draft be descriptive or prescriptive? In other words,
> > should this draft describe what is happening in the real-world or what
> > the WG plans to see. We think this draft is to capture what is
> > happening in the real-world.
> >
> > Q2: Should the SBC reset the Max-Forwards? In our network, the SBC
> > does reset the Max-Forwards. However, the IESG thinks the SBC should
> > decrement the Max-Forwards rather than resetting it. This is back to
> > Q1, should this draft be descriptive or prescriptive.
> >
> > After we receive comments from the WG, we will update the draft and
> > release a new revision.
> >
> > Thanks,
> > Adam and Yiu
> >

---

From: "Terry Martin" <[email-masked]>
Date: Tue, 1 Dec 2009 17:09:42 -0500

Thanks to all for addressing the question.

What I have seen so far is this appears to be a legitimate recommendation, under certain conditions, which means it should be added to document for consideration

Terry Martin
TimeData Corporation
VP of Network Operation

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 2:03 PM
To: Lee, Yiu; Terry Martin; [email-masked]
Subject: RE: [Speermint] VoIP Use Cases Questions

Mike

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Dec 2009 19:06:33 -0500

Agreed that by decrementing the Max-Forward can prevent from possible
looping. I have no problem to update the draft to reflect the change if I
hear no objection from the list. One thing I want to mention is that this
draft isn't intended to be BCP, so call flows captured in this draft are
only informative.

On 12/1/09 5:02 PM, "Mike Hammer (hmmr)" <[email-masked]> wrote:

> The benefit of not resetting but decrementing relates to the possibility that
> this peering point is one of a series where other interfaces could lead to
> possible looping of a call.  Problem is that you can't always guarantee what
> happens at the next hop.
> 
> Mike
> 
>

---

From: Bob Penfield <[email-masked]>
Date: Tue, 1 Dec 2009 19:09:53 -0500

Our SBC does decrement Max-Forwards. It's the right thing to do.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Dec 2009 10:35:45 +0100

The purpose of the Max-Forward header field is to limit the lifetime of the request in the call as a whole, i.e. that something must have gone wrong in the routeing if it expires. By resetting the Max-Forward header field on exit from the subnetwork bounded by the SBC, you assume the routeing between and beyond subnetworks is perfect and requests cannot get lost in this space. Such thoughts are a fallacy. I could understand a methodology of adding counts, if you thing you have taken rather more than your fair share within the subnetwork, but resetting to its default value is in my view erroneous.

Keith

> Sent: Tuesday, December 01, 2009 7:40 PM
> You don't have to be the member of the team to give us 
> comments. We welcome you for any feedback.
> 
> For the Max-Forward question, the IESG believes that the SBC 
> is only a hop of the call, so it should not reset the 
> Max-Forward. Rather, it should just decrement the 
> Max-Forward. Other than that, I can't think of any benefit.
> 
> Yiu
> 
> 
> > some prescriptive definitions to improve on real world 
> implementation issues.
> >

---

From: Daryl Malas <[email-masked]>
Date: Wed, 02 Dec 2009 14:50:18 -0700

I agree from the standpoint I do not think SBC's should reset the
Max-Forward value.

--Daryl

On 12/2/09 2:35 AM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

> The purpose of the Max-Forward header field is to limit the lifetime of the
> request in the call as a whole, i.e. that something must have gone wrong in
> the routeing if it expires. By resetting the Max-Forward header field on exit
> from the subnetwork bounded by the SBC, you assume the routeing between and
> beyond subnetworks is perfect and requests cannot get lost in this space. Such
> thoughts are a fallacy. I could understand a methodology of adding counts, if
> you thing you have taken rather more than your fair share within the
> subnetwork, but resetting to its default value is in my view erroneous.
> 
> Keith
> 

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 15 Dec 2009 21:46:08 +0100

On Tue, Dec 1, 2009 at 8:40 PM, Lee, Yiu <[email-masked]> wrote:
> decrement the Max-Forward.

I support this opinion.
-- 
Victor Pascual Ávila

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 16 Dec 2009 07:36:22 -0500

Hi Victor,

This change has been updated in version 15.

Thanks,
Yiu