headers
Jozef Babiarz | 2 Jun 2004 03:31

RE: draft-baker-diffserv-basic-classes-02

In a message dated May 27, 2004 Mpierce1 <at> aol.com writes:

[Mike]

I believe this remains as one of the major open questions for the application of SIP or H.323 in a large, managed network. Some comments:

I've heard of speech clipping (on answer), but I don't know what "ring-clipping" is. I presume you are referring to call setup delay (or delay to ring). The issue is signaling delay in general (call setup and release), but speech clipping has always been the most serious impact of delay.

It seems to me that this issue is really not related to "interfacing to a TDM telephony switch", but occurs equally within a fully IP environment.

[Joe]

Ring-clipping can occur if SS7 signaling path from the softswitch to the TDM CO is much faster than the signaling path from softswitch to IP gateway that interfaces to the TDM CO were the ringing tone is generated. Speech-clipping can occur if the signaling path from the call answered phone to the softswitch and back to the IP gateway that enables the audio path takes longer then for the person answering the phone to say hello.

 

[Mike]

No matter what service class is used for signaling (above, below, or same as speech bearer) there must be guaranteed bandwidth for the expected signaling traffic to provide sufficient low latency and almost zero discard rate independent from the amount of speech bearer traffic. In effect, if signaling is in a separate class and is guaranteed, say 5% of the bandwidth on an outgoing link and speech bearer (EF) is guaranteeed 50%, then it isn't really necessary to think of one being above or below or the same as the other. The forwarding algorithm guarantees a minimum bandwidth to both in what is effectively "time-division multiplexing", but we don't call it that since it is not based on strict timing. The result is that the signaling does not experience "higher latency", but probably has "higher delay variation", mostly due to the varying packet sizes.

[Joe]

Agree. Putting signaling traffic into a distinct class and engineering that class so that queuing dose not occur does work. In next draft (03) I will total separate telephony signaling from telephony bearer traffic.

 

Regards,

Joe Babiarz
 

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Permalink | Reply | 0 comments |
headers
Jozef Babiarz | 2 Jun 2004 03:35

RE: draft-baker-diffserv-basic-classes-02

In next version 03 of the draft will make the change so that telephony signaling and telephony bearer traffic are in different classes. Thanks for your comments.

Regards, Joe.

-----Original Message-----
From: Fil Dickinson [mailto:Fil.Dickinson <at> optus.com.au]
Sent: Tuesday, May 25, 2004 12:27 AM
To: tsvwg <at> ietf.org
Subject: [Tsvwg] draft-baker-diffserv-basic-classes-02

My understanding of this draft is that it proposes the Voice signalling and
Voice Bearer are transported in the same class with the exception being
"signaling flows between high capacity telephony call servers or soft
switches".
I am concerned with this. During testing of our multi-vendor converged
network I have seen that oversubscribed voice bearer traffic can disrupt the
voice signalling traffic which results in abnormal operation of all voice
calls [re-registration (outage) of IP Phones]. I would like to see this
addressed by a draft that mandates All Voice Signalling and Voice Bearer
traffic operate in distinct classes. Ie, a Telephony Signalling Service
Class and a Telephony Bearer Service Class.

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg 

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Permalink | Reply | 0 comments |
headers
Meyknecht Bernward | 4 Jun 2004 17:50
Picon

what is a 'sufficiently' long idle period ?


Hi all,

in SCTP RFC and Implem. Guide there's a sentence telling me how to initialize the 
cwnd after a 'sufficiently' long idle period.

Does anyone have a proposal what could be a good value for 'sufficiently' ?
5, 10, 20 times RTO ? ....

Text from ch. 2.30 / implem. guide:
--------- New text: (Section 7.2.1) --------- o 
The initial cwnd before DATA transmission or after a sufficiently long idle period 
MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). 

--- --- ---

And how does this match ch. 2.14 from implem guide, where I'm told to set cwnd 
to 2*MTU after one RTO, which could be less than the value from above.
Does the formula from 2.30 replace the one from 2.14?

Text from ch. 2.14 / implem. guide:
--------- New text: (Section 7.2.1) --------- o 
When the association does not transmit data on a given transport address within an RTO, 
the cwnd of the transport address SHOULD be adjusted to 2*MTU. 

Maybe someone has some idea...

Best regards,

Bernward
Permalink | Reply | 1 comment |
headers
Michael Tuexen | 5 Jun 2004 18:48
Picon

Registration for 7th SCTP Interop is open and ends at June 18th

Dear all,

the 7th SCTP interop will be held at University of Applied Sciences, 
Münster, from
July 25th to July 30th 2004.

Tested specifications include RFC 2960, RFC 3309, RFC 3758, the 
Implementers Guide,
ADD-IP Extension, PKTDRPREP Extension and the SCTP MIB.

In addition to the 'usual' setup there will be a Gigabit Ethernet for
performance testing.

You can register until June 18th and find more information at
http://sctp.fh-muenster.de

If you have any further questions please do not hesitate to contact me 
via
tuexen <at> fh-muenster.de

Happy SCTPing
Michael
Permalink | Reply | 0 comments |
headers
Sally Floyd | 7 Jun 2004 21:17

Errata for RFC 3448, "TCP Friendly Rate Control (TFRC)"

This is a notice that I am sending in an Errata to the
RFC Editor for RFC 3448.  This is from errata that has been
on the TFRC web page for over a year, but that I have never
managed to send in the RFC Editor for the "RFC Errata" web page.   
FYI.

- Sally
http://www.icir.org/tfrc/

The RFC 3448 Errata:

RFC 3448, TCP Friendly Rate Control (TFRC): Protocol Specification

Reported By: Joerg Widmer
Date: March 4, 2003

* Nofeedback timeout:  Correct an inconsistency in the document.

In Section 4:

"If the sender does not receive a feedback report for two round
trip times, it cuts its sending rate in half."

Should be: 

"If the sender does not receive a feedback report for four round
trip times, it cuts its sending rate in half."

Reported By: Mark Handley, from Wim Heirman
Date: March 13, 2003

In Section 4.4, item (2):

      If the nofeedback timer expires when the sender does not yet have
      an RTT sample, and has not yet received any feedback from the
      receiver,

Should be:

      If the nofeedback timer expires when the sender does not yet have
      an RTT sample, and has not yet received any feedback from the
      receiver, or when p == 0,

Reported By: Sally Floyd, from Michele R.
Date: April 29, 2003

* In Section 5.5, when initializing DF, initialize from 0 to n, not from 
* 1 to n:

In Section 5.5:

      for (i = 1 to n) {
        DF_i = 1;
      }

Should be: 

      for (i = 0 to n) {
        DF_i = 1;
      }
Permalink | Reply | 0 comments |
headers
Randall R. Stewart (home | 8 Jun 2004 14:28
Picon
Picon

Re: what is a 'sufficiently' long idle period ?

Bernward:

IMO you really do not need to do the cwnd reduction if
you are applying a burst limit... this whole reduction thing (I think)
needs to be revisited with respect to burst limit and of course
how long it takes to degrade the cwnd...

R

Meyknecht Bernward wrote:

>Hi all,
>
>in SCTP RFC and Implem. Guide there's a sentence telling me how to initialize the 
>cwnd after a 'sufficiently' long idle period.
>
>Does anyone have a proposal what could be a good value for 'sufficiently' ?
>5, 10, 20 times RTO ? ....
>
>Text from ch. 2.30 / implem. guide:
>--------- New text: (Section 7.2.1) --------- o 
>The initial cwnd before DATA transmission or after a sufficiently long idle period 
>MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). 
>
>--- --- ---
>
>And how does this match ch. 2.14 from implem guide, where I'm told to set cwnd 
>to 2*MTU after one RTO, which could be less than the value from above.
>Does the formula from 2.30 replace the one from 2.14?
>
>Text from ch. 2.14 / implem. guide:
>--------- New text: (Section 7.2.1) --------- o 
>When the association does not transmit data on a given transport address within an RTO, 
>the cwnd of the transport address SHOULD be adjusted to 2*MTU. 
>
>Maybe someone has some idea...
>
>
>Best regards,
>
>Bernward
>
>
>
>_______________________________________________
>tsvwg mailing list
>tsvwg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
>  
>

--

-- 
Randall R. Stewart
815-477-2127 (office)
815-342-5222 (cell phone)
Permalink | Reply | 0 comments |
headers
Meyknecht Bernward | 8 Jun 2004 15:04
Picon

AW: what is a 'sufficiently' long idle period ?


Hi Randy,

thanks for your reply, yes these cwnd reduction things look strange
for me in some aspects...

As long as my burst limit allows me to send as much data as the actual 
reduced cwnd would allow, in this case, I would be content with 
skipping all these cwnd reduction things, and if you set the 
cwnd to small 2*mtu, this will be the case.

Anyhow I don't like the immediate reduction to 2*mtu after a single 
rto, reduction to min (4*MTU, max (2*MTU, 4380 bytes)) looks 
more logical to me, and... without having a closer look.. I still 
like the idea of setting cwnd to cwnd/2 per rto til 
min (4*MTU, max (2*MTU, 4380 bytes)) is reached. For the case where
a big cwnd/2 still allows to send more than my burst limit 
would allow.

Best regards,
Bernward

-----Ursprungliche Nachricht-----
Von: Randall R. Stewart (home) [mailto:randall <at> stewart.chicago.il.us]
Gesendet: Dienstag, 8. Juni 2004 14:28
An: Meyknecht Bernward
Cc: tsvwg <at> ietf.org
Betreff: Re: [Tsvwg] what is a 'sufficiently' long idle period ?

Bernward:

IMO you really do not need to do the cwnd reduction if
you are applying a burst limit... this whole reduction thing (I think)
needs to be revisited with respect to burst limit and of course
how long it takes to degrade the cwnd...

R

Meyknecht Bernward wrote:

>Hi all,
>
>in SCTP RFC and Implem. Guide there's a sentence telling me how to initialize the 
>cwnd after a 'sufficiently' long idle period.
>
>Does anyone have a proposal what could be a good value for 'sufficiently' ?
>5, 10, 20 times RTO ? ....
>
>Text from ch. 2.30 / implem. guide:
>--------- New text: (Section 7.2.1) --------- o 
>The initial cwnd before DATA transmission or after a sufficiently long idle period 
>MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). 
>
>--- --- ---
>
>And how does this match ch. 2.14 from implem guide, where I'm told to set cwnd 
>to 2*MTU after one RTO, which could be less than the value from above.
>Does the formula from 2.30 replace the one from 2.14?
>
>Text from ch. 2.14 / implem. guide:
>--------- New text: (Section 7.2.1) --------- o 
>When the association does not transmit data on a given transport address within an RTO, 
>the cwnd of the transport address SHOULD be adjusted to 2*MTU. 
>
>Maybe someone has some idea...
>
>
>Best regards,
>
>Bernward
>
>
>
>_______________________________________________
>tsvwg mailing list
>tsvwg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
>  
>

--

-- 
Randall R. Stewart
815-477-2127 (office)
815-342-5222 (cell phone)
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 10 Jun 2004 21:58
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-addip-sctp-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: Stream Control Transmission Protocol (SCTP) Dynamic 
			  Address Reconfiguration
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-addip-sctp-09.txt
	Pages		: 37
	Date		: 2004-6-10
	
This document describes extensions to the Stream Control Transmission
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
address information on an existing association.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-addip-sctp-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 140 bytes
Attachment (draft-ietf-tsvwg-addip-sctp-09.txt): message/external-body, 69 bytes
_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Permalink | Reply | 0 comments |
headers
Straub Gilles | 14 Jun 2004 15:39

Are IP routers transparent to UDP Lite ?

Hello All,

I am trying to evaluate UDP Lite technique. I had a look to the 2003 draft
on this matter.
I had a question regarding UDB checksum processing in IP routers : although,
in principle a transport layer is processed in end to end (in source and
destination), I wanted to check that no CRC check is performed in IP routers
: is anybody aware of IP routers where UDP or TCP checksum computation
(check & discard) is or can be enabled ? 

If UDP checksum computation is always done in the host only, then UDP lite
applications can be developped on existing internet, otherwise, this would
require router modifications.
Thanks in advance for any feedback I would get on this topic

Best Regards

Gilles STRAUB
gilles.straub <at> thomson.net
THOMSON
Permalink | Reply | 2 comments |
headers
Joe Touch | 14 Jun 2004 21:16
Picon
Favicon

Re: Are IP routers transparent to UDP Lite ?


Straub Gilles wrote:

> Hello All,
> 
> 
> I am trying to evaluate UDP Lite technique. I had a look to the 2003 draft
> on this matter.
> I had a question regarding UDB checksum processing in IP routers : although,
> in principle a transport layer is processed in end to end (in source and
> destination), I wanted to check that no CRC check is performed in IP routers
> : is anybody aware of IP routers where UDP or TCP checksum computation
> (check & discard) is or can be enabled ? 

That would kill IPsec'd packets... a protection that would defeat IPsec 
isn't very protective ;-(

> If UDP checksum computation is always done in the host only, then UDP lite
> applications can be developped on existing internet, otherwise, this would
> require router modifications.

Any router that performed that sort of delayed fill-in or check is 
basically performing as a host anyway. It would need to be updated as 
any host would, if the transport protocols supported changed.

Joe

> Thanks in advance for any feedback I would get on this topic
> 
> Best Regards
> 
> 
> Gilles STRAUB
> gilles.straub <at> thomson.net
> THOMSON
> 
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Permalink | Reply | 0 comments |

Gmane