headers
Randall Stewart | 1 Apr 2007 14:09

Re: Socket API draft

Sirigiri, Anil Kumar Reddy (STSD) wrote:
> Hi,
> 
> Can someone please clarify my following doubts about socket API draft:
> 
> 1/ Should there be a bind() prior to sctp_bindx() ? -- I see it
> mentioned in one of tsvwg's mails, in the past, but couldn't find an
> answer.

In theory you should be able to use sctp_bindx instead of bind().

> 
> 2/ What is the use of sctp_opt_info() to have assoc_id as the parameter
> ? I see that all sctp_opt_info() options are having the assoc_id in the
> option argument structures. Though, there is no harm in having it, I
> just have this question out of curiosity to know the reason behind it.

sctp_opt_info() was created for O/S's that cannot pass information
in on a getsockopt() call. You want to pass info in when you are
explicitly getting information on an association. In BSD land
either sctp_opt_info or getsockopt() will work.. in fact sctp_opt_info
just calls a getsockopt()... since BSD allows the passing of
information in to the getsockopt call.

Other o/s's .. for example solaris .. use a streams based stack
which is pretty strict on not allowing data coming in to a
getsockopt call.. at least thats what I have been told.

Hope that helps..
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian F. G. Bidulock | 1 Apr 2007 15:11
Favicon

Re: Socket API draft

Randall,

Randall Stewart wrote:                        (Sun, 01 Apr 2007 08:09:06)
> 
> sctp_opt_info() was created for O/S's that cannot pass information
> in on a getsockopt() call. You want to pass info in when you are
> explicitly getting information on an association. In BSD land
> either sctp_opt_info or getsockopt() will work.. in fact sctp_opt_info
> just calls a getsockopt()... since BSD allows the passing of
> information in to the getsockopt call.
> 
> Other o/s's .. for example solaris .. use a streams based stack
> which is pretty strict on not allowing data coming in to a
> getsockopt call.. at least thats what I have been told.

STREAMS XTI/TPI supports both getsockopt() and setsockopt() through
a single options management request interface.  Information is both
transferred in and transferred out in the same call.  So, not only
can options mangement pass information with a get operation, it can
retrieve information with a set operation.

 http://www.openss7.org/man2html?3+t_optmgmt
 http://www.openss7.org/man2html?7+T_OPTMGMT_REQ
 http://www.openss7.org/man2html?7+T_OPTMGMT_ACK

Any limitation is certainly not the fault of the TPI interface.

--brian

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Eggert | 2 Apr 2007 18:37
Picon
Gravatar

Re: EF DSCP for Capacity-Admitted Traffic (was: Re: TSVWG meeting"hum" confirmations with the list)

On 2007-3-29, at 13:12, ext Romascanu, Dan (Dan) wrote:
>> From: Lars Eggert [mailto:lars.eggert <at> nokia.com]
>> Now, the issue seems to be that if you throw flows of
>> different media types into that traffic class - even if their
>> aggregate bandwidth use is within capacity - this can result
>> in unacceptable media quality in some (many?) scenarios.
>
> Why that? Assuming that the capacity threshold according to which the
> admission happens is computed correctly, why should unacceptable media
> result for traffic admitted within limits.

As I understand it - and someone needs to really jump in here and  
tell me whether I've understood it - is that jitter gets sufficiently  
bad to really affect voice quality, even under low loss. Remember  
that this is for interactive traffic.

>> What worries me is that I see no indication that two DSCPs is
>> all that will be needed. The current deployment interest
>> seems to be in mixing CAC voice and video, but will we need
>> to allocate additional DSCPs when deployments want to
>> capacity-admit additional types of traffic? How many?
>
> This argument seems to me valid. Actually I doubt that mixing CAC  
> voice
> and video is a good thing in many real scenarios as bandwidth, traffic
> profile and QoS metrics largely differ for voice-only and
> voice-and-video applications.

I don't follow, can you clarify? Your first sentence agrees with the  
argument (that we're on a slippery slope towards per-media-type
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sirigiri, Anil Kumar Reddy (STSD | 3 Apr 2007 12:04
Picon
Favicon

RE: Socket API draft


: > 2/ What is the use of sctp_opt_info() to have assoc_id as the 
: > parameter ? I see that all sctp_opt_info() options are having the 
: > assoc_id in the option argument structures. Though, there 
: is no harm 
: > in having it, I just have this question out of curiosity to 
: know the reason behind it.
: 
: sctp_opt_info() was created for O/S's that cannot pass 
: information in on a getsockopt() call. You want to pass info 
: in when you are explicitly getting information on an 
: association. In BSD land either sctp_opt_info or getsockopt() 
: will work.. in fact sctp_opt_info just calls a 
: getsockopt()... since BSD allows the passing of information 
: in to the getsockopt call.

Thanks for clarifying this. Yes, I got this point from the draft -- I do
not have any questions on the 'need' of it. My question is related to
the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
my previous mail. Considering the following API syntax:

	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
socklen_t *size);

Here, why do we have 'id' (association id) as the parameter when we
already have this as a member in all opt's "arg" structures applicable
to sctp_opt_info() ? 

--
Anil
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randall Stewart | 3 Apr 2007 14:18

Re: Socket API draft

Sirigiri, Anil Kumar Reddy (STSD) wrote:
> : > 2/ What is the use of sctp_opt_info() to have assoc_id as the 
> : > parameter ? I see that all sctp_opt_info() options are having the 
> : > assoc_id in the option argument structures. Though, there 
> : is no harm 
> : > in having it, I just have this question out of curiosity to 
> : know the reason behind it.
> : 
> : sctp_opt_info() was created for O/S's that cannot pass 
> : information in on a getsockopt() call. You want to pass info 
> : in when you are explicitly getting information on an 
> : association. In BSD land either sctp_opt_info or getsockopt() 
> : will work.. in fact sctp_opt_info just calls a 
> : getsockopt()... since BSD allows the passing of information 
> : in to the getsockopt call.
> 
> Thanks for clarifying this. Yes, I got this point from the draft -- I do
> not have any questions on the 'need' of it. My question is related to
> the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
> my previous mail. Considering the following API syntax:
> 
> 	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
> socklen_t *size);
> 
> Here, why do we have 'id' (association id) as the parameter when we
> already have this as a member in all opt's "arg" structures applicable
> to sctp_opt_info() ? 
> 
I believe it would probably be for the same reason that
Kacheong sites that we have the call in the first place...
(Continue reading)

Permalink | Reply | 0 comments |
headers
James M. Polk | 4 Apr 2007 00:40
Picon
Favicon

*Draft* meeting minutes from Prague now available

These are the *draft* TSVWG minutes from our Prague meetings.

         http://www3.ietf.org/proceedings/07mar/minutes/tsvwg.txt

Comments and corrections are welcome

Cheers,
James
IETF TSVWG co-chair

              ***********************************
     "It should NEVER be inconvenient to do the right thing"
Permalink | Reply | 0 comments |
headers
Jozef Babiarz | 4 Apr 2007 00:56
Favicon

RE: EF DSCP for Capacity-Admitted Traffic (was: Re: TSVWG meeting"hum" confirmations with the list)

On April 2, 2007 Lars Eggert wrote:
>I'd be happier if we could draw a boundary between these two kinds of  
>traffic that aren't based on media types, because that'd give me some  
>reassurance that we're not setting ourselves up for many more future  
>registrations.
>
>Idea: can we reclassify "capacity admitted voice" as "capacity  
>admitted low-jitter" traffic, and "capacity-admitted video" as  
>"capacity admitted high-bandwidth", and argue that the former should  
>have precedence over the latter? (Or something like this; my proposal  
>may be naive.)
I'm OK with classify it for "capacity admitted low-jitter" traffic. I
believe that voice was only an example as it will mostly be the first
use case. Same for "capacity admitted high-bandwidth", MPEG4 video flows
would be an example of traffic that would use this DSCP. My view is that
any flow that fits the defined characteristics and performance
requirements can use this capability and is not limited to voice or
video flows. 

Regards, Joe
email:babiarz <at> nortel.com
Telephone:613-763-6098
-----Original Message-----
From: Lars Eggert [mailto:lars.eggert <at> nokia.com] 
Sent: April 2, 2007 12:37 PM
To: ext Romascanu, Dan (Dan)
Cc: ext James M. Polk; tsvwg
Subject: Re: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg]
TSVWG meeting"hum" confirmations with the list)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Eggert | 4 Apr 2007 10:41
Picon
Gravatar

Re: WGLC for draft-ietf-tsvwg-2960bis-02 starts NOW

On 2007-3-26, at 18:06, ext Lars Eggert wrote:
>
> Apologies to the authors - we dropped the ball on this one over the  
> holidays. There was significant discussion on -02 that lead to -03  
> being submitted to the secretariat some months ago, but it didn't  
> get published until last week. We're currently trying to find out  
> exactly what went wrong.
>
> In the meantime: Please take a look at -03 and send final WGLC  
> comments until April 8.

Four days left. Current consensus - based on the comments from last  
year - seems to be to request publication. Please speak up if you  
agree or disagree.

Lars
Permalink | Reply | 0 comments |
headers
Kacheong Poon | 4 Apr 2007 12:45
Picon

Re: Socket API draft

Sirigiri, Anil Kumar Reddy (STSD) wrote:

> Thanks for clarifying this. Yes, I got this point from the draft -- I do
> not have any questions on the 'need' of it. My question is related to
> the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
> my previous mail. Considering the following API syntax:
> 
> 	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
> socklen_t *size);
> 
> Here, why do we have 'id' (association id) as the parameter when we
> already have this as a member in all opt's "arg" structures applicable
> to sctp_opt_info() ? 

My vague memory suggested that that this may an historical
artifact in the merge of 1-1 and 1-N style SCTP socket.  In
the pre-00 version of the draft, I believe there was no
association ID in those socket option structures.  So there
was a need for the ID in the sctp_opt_info().  Then the same
structures were modified to have the association ID.  Since
it is better for both getsockopt() and sctp_opt_info() to use
the same structures and we didn't want to change the function
prototype, it was kept.  Note that this was just from memory...

BTW, in the 00 version of the draft, the text for sctp_opt_info()
was written as

  getsockopt() is read-only, so a new interface is required when
  information must be passed both in to and out of the SCTP stack.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tuexen | 4 Apr 2007 13:57
Picon

Re: ephemeral ports and bindx

Randy,

I'm not sure if it is a good idea to silently accept things
from the user (x,y) which are wrong without complaining, just
ignoring...

So what about:

1. allow bindx() after bind() or without bind().
2. if in bind() or bindx() any non-zero port number
    is used and checked. This allows explicit binding
    with bind() and bindx(). It required to use the
    same non-zero port number in all bindx() calls.
3. If a zero port number is used the kernel will
    chose an ephemeral one if the socket is unbound
    or will use the already known one if the socket
    is bound.

If something goes wrong, return an error.

Best regards
Michael

On Apr 4, 2007, at 12:42 PM, Randall Stewart wrote:

> Jan:
>
> Well I was wrong..
>
> BSD does NOT act the way you describe that linux does.. and in
(Continue reading)

Permalink | Reply | 51 comments |

Gmane