Subject: [Sipping] Re: WGLC: draft-ietf-sipping-overload-reqs-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 00:26:40 -0500

Well, an update of this document is extremely delinquint (5 months 
overdue!), for which I apologize.

Thanks for your comments, Mary.

In terms of yours and Volker's comment about the simulation model 
aligning with the design team, I agree that it should. However, this 
model has been somewhat of a moving target. As we do simulations, issues 
come up that require a change or clarification in the model. Also, we 
have determined that we'll need a few models of varying complexity to 
evaluate the algorithms in stages.

Given all of that, I propose to remove the simulation model from this 
document. It was originally added for the following reasons:

* Allow non-SIP experts to assist in understanding the problem and solution
	Request from TSVWG last two meetings
* Allow SIP WG to have a benchmark for evaluating alternative solutions
* Allow SIPPING/SIP WG to have a model for understanding the problem

These are all good goals but don't require the model to be here, in the 
overload requirements document itself. Indeed, it seems much better 
suited to place the model in a document which reports the actual 
simulation results along with it, which we agreed later (after the model 
had been added to the document) would be a good info document to get out 
of the design team when finished.

Please comment if you disagree and think the model belongs here. I'll be 
posting a separate note on this so its not just buried in this thread.

Thanks,
Jonathan R.

Mary Barnes wrote:
> Draft: draft-ietf-sipping-overload-reqs-00
> Reviewer: Mary Barnes
> Review Date: May 21, 2007
> Review Deadline: May 21, 2007
> Status: WGLC
> 
> Summary: This draft is basically ready for publication, but has nits 
> that should be fixed before publication.
> 
> Nits:
> - Need to add the Intended Status to the header: category="info" 
> - Section 6 (General):  I agree with Volker's suggestion that this
> section should match the agreed modeling approach from the design team 
> - Section 6.1: qualifying the parameters in section 6 with the units
> would make it more readable (e.g., "Saccess" -> "Saccess bits" and
> "Score" -> "Score bits") 
> - Section 6.3: per comment above on 6.1, "Srin" -> "Srin bits"
> - Figure 6: "Spkit" -> "Spkt"  (or change the reference in 6.2 to
> "Spkit")
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 01:05:54 -0500

Thanks for the review comments, Spencer. And to you also I owe an 
apology for the very tardy and delinquint response and document update. 
Responses below.

Spencer Dawkins wrote:
> Reviewer: Spencer Dawkins
> Review Date: May 27, 2007
> Review Deadline: May 21, 2007 (whoops!)
> Status: WGLC
> 
> Summary: This draft is basically ready for publication, but I do have a 
> couple of comments.
> 
> Comments:
> 
> This draft is very well-written and very readable.
> 
> This draft seems to sidestep interaction with TCP (and SCTP) 
> retransmission behavior. The current focus on UDP is the right place to 
> start, but perhaps it's worth looking at non-datagram transports in a 
> separate draft, and/or at some point in the future.

great point. The discussion in section 4.1 is heavily skewed towards 
UDP. Its an unstated assumption in fact. I've fixed this, so that it 
explicitly says UDP and indicates how TCP is impacted. Generally, TCP is 
better, but you can still have retransmits of segments if the kernel 
can't acknowledge them fast enough.

I fixed the nits below.

Thanks,
Jonathan R.

> Nits:
> 
> There are a bunch of nits identified (mostly related to the age of the 
> current version of the draft, etc). Here's what got flagged, though.
> 
> idnits 2.04.07
> 
> tmp/draft-ietf-sipping-overload-reqs-00.txt:
> 
>  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
>  ---------------------------------------------------------------------------- 
> 
> 
>  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
>     instead of the newer IETF Trust Copyright according to RFC 4748.
> 
>  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
>     of the newer disclaimer which includes the IETF Trust according to RFC
>     4748.
> 
> 
>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>  ---------------------------------------------------------------------------- 
> 
> 
>  == No 'Intended status' indicated for this document; assuming Proposed
>     Standard
> 
> 
>  Checking nits according to http://www.ietf.org/ID-Checklist.html:
>  ---------------------------------------------------------------------------- 
> 
> 
>  ** There are 5 instances of too long lines in the document, the longest 
> one
>     being 3 characters in excess of 72.
> 
>  ** The document seems to lack a both a reference to RFC 2119 and the
>     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
>     keywords.
> 
>     RFC 2119 keyword, line 176: '...er is given, the client MUST act as 
> if...'
>     RFC 2119 keyword, line 180: '...to an alternate server.  It SHOULD 
> NOT...'
>     RFC 2119 keyword, line 184: '...      Servers MAY refuse the 
> connectio...'
>     RFC 2119 keyword, line 195: '...   at SHOULD NOT strength.  This is 
> to...'
> 
>  Miscellaneous warnings:
>  ---------------------------------------------------------------------------- 
> 
> 
>  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
>     match the current year
> 
> 
>  Checking references for intended status: Proposed Standard
>  ---------------------------------------------------------------------------- 
> 
> 
>  == Outdated reference: A later version (-08) exists of
>     draft-ietf-sip-outbound-04
> 
> 
>     Summary: 4 errors (**), 3 warnings (==), 0 comments (--).
> 
>     Run idnits with the --verbose option for more detailed information 
> about
>     the items above.
>