Cullen Jennings | 1 Aug 2011 21:48
Picon
Favicon
Gravatar

Re: Sessmatch products


old reply in my drafts folder ...

On May 26, 2011, at 3:46 AM, Christer Holmberg wrote:

> 
> In sessmatch mode the troughput for MSRP packets is line-interface wirespeed, while in MSRP B2BUA mode
the maximum throughput for MSRP packets is much lower.

I'm pretty confused on how dealing with the SIP need to look at the path or just modify the SDP has an impact on
the speed or sending MSRP packets once the session is set up. Of course I support the goal of rapid
forwarding of MSRP packets once the session is set up. I can't see any  problem with archiving wireline
speed forwarding of packets thorough an MSRP relay. 
Christer Holmberg | 2 Aug 2011 00:19
Picon
Favicon

Re: Sessmatch products


Hi Cullen, 

>>In sessmatch mode the troughput for MSRP packets is 
>>line-interface wirespeed, while in MSRP B2BUA mode the 
>>maximum throughput for MSRP packets is much lower.
> 
>I'm pretty confused on how dealing with the SIP need to look 
>at the path or just modify the SDP has an impact on the speed 
>or sending MSRP packets once the session is set up. Of course 
>I support the goal of rapid forwarding of MSRP packets once 
>the session is set up. I can't see any  problem with 
>archiving wireline speed forwarding of packets thorough an 
>MSRP relay. 

I am not sure I understood you correctly, but yhe impact comes when a middlebox needs to modify the MSRP
messages (MSRP B2BUA mode), rather than simply forwarding them.

Regards,

Christer
Ben Campbell | 2 Aug 2011 02:58
Favicon

Re: Sessmatch products

I think the confusion was around the term "MSRP B2BUA". Christer has agreed to define this in the next
revision of the draft.

Thanks!

Ben.

On Aug 1, 2011, at 6:19 PM, Christer Holmberg wrote:

> 
> Hi Cullen, 
> 
>>> In sessmatch mode the troughput for MSRP packets is 
>>> line-interface wirespeed, while in MSRP B2BUA mode the 
>>> maximum throughput for MSRP packets is much lower.
>> 
>> I'm pretty confused on how dealing with the SIP need to look 
>> at the path or just modify the SDP has an impact on the speed 
>> or sending MSRP packets once the session is set up. Of course 
>> I support the goal of rapid forwarding of MSRP packets once 
>> the session is set up. I can't see any  problem with 
>> archiving wireline speed forwarding of packets thorough an 
>> MSRP relay. 
> 
> I am not sure I understood you correctly, but yhe impact comes when a middlebox needs to modify the MSRP
messages (MSRP B2BUA mode), rather than simply forwarding them.
> 
> Regards,
> 
> Christer
(Continue reading)

Cullen Jennings | 2 Aug 2011 22:27
Picon
Favicon
Gravatar

Re: Sessmatch products


On Aug 1, 2011, at 15:19 , Christer Holmberg wrote:

> 
> Hi Cullen, 
> 
>>> In sessmatch mode the troughput for MSRP packets is 
>>> line-interface wirespeed, while in MSRP B2BUA mode the 
>>> maximum throughput for MSRP packets is much lower.
>> 
>> I'm pretty confused on how dealing with the SIP need to look 
>> at the path or just modify the SDP has an impact on the speed 
>> or sending MSRP packets once the session is set up. Of course 
>> I support the goal of rapid forwarding of MSRP packets once 
>> the session is set up. I can't see any  problem with 
>> archiving wireline speed forwarding of packets thorough an 
>> MSRP relay. 
> 
> I am not sure I understood you correctly, but yhe impact comes when a middlebox needs to modify the MSRP
messages (MSRP B2BUA mode), rather than simply forwarding them.
> 

Well, what modifications are we talking about here and how much time do we think it will take? I'm not looking
for exact measurements or anything but lets just work through how hard this is to do at wireline speeds. 
Ben Campbell | 5 Aug 2011 22:19
Favicon

Draft Minutes from SIMPLE <at> IETF81

The following are draft minutes from the SIMPLE meeting in Quebec. Please send any corrections as soon as possible.

Thanks!

Ben.

-----------------------------------------------------------------------------------------------------

[DRAFT] Minutes - SIMPLE IETF 81 - Friday 29 July 2011 - Quebec, QC, CA

Summary:

-- Status: 

Only 3 remaining work items: draft-ietf-simple-chat, draft-ietf-simple-simple,
draft-ietf-simple-msrp-sessmatch. We expect to pubreq the chat draft soon. Simple-simple is waiting
completion of the other drafts, but should finish quickly. Msrp-sessmatch to be discussed in this meeting.

-- draft-ietf-simple-msrp-sessmatch

Christer presented changes. The latest version is a significant departure from previous versions. The
primary changes (use of C and M lines rather than MSRP URI for connection management) appear to have
support on the list and in the room. Eric Burger and Christer Holmberg will spin a new revisions, which will
be followed by a WGLC. The AD suggested changing the draft name to reflect the new approach. The chairs will
encourage people who have expressed issues with previous revisions to speak up quickly if they still have
issues with the new version.

Raw notes follow:

Notes from Christian Schmidt:
(Continue reading)

Eric Burger | 5 Aug 2011 22:44

Re: Draft Minutes from SIMPLE <at> IETF81

inline

On Aug 5, 2011, at 4:19 PM, Ben Campbell wrote:
[snip]
> Ben Campbell  (Individual): I  want to see a table, when middlebox have
> to be B2BUA. I am worried about complexity for middleboxes.
> Christer Holmberg: We do not request new functionality for middlebox.
> They just decide functionality according the CEMA paramater.
> Ben Campbell: If this approach is similar complex as RFC4976, then this
> makes no sense.
> Christer Holmberg: If this would be the case, I would make the same
> statement, but that is not the case.
> Eric Burger: This is not about making things easier for middleboxes. It
> is about to overcome a failure in middleboxes. And it makes

s/overcome a failure in middleboxes/overcome a failure in MSRP/

> implementations for middleboxes much simpler. I am willing to spend a
> small increse of complexity now for this purpose.
> Ben Campbell: Keep in mind, we make no normative statements, how
> middleboxes work. We can not force middleboxes to implement MSRP B2BUA. 
> Eric Burger: This is the reason, why this draft is important.
> Ben Campbell: 3GPP can make requirements for middleboxes. 
[snip]
Attachment (smime.p7s): application/pkcs7-signature, 3932 bytes
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
(Continue reading)

Saúl Ibarra Corretgé | 8 Aug 2011 09:28
Favicon
Gravatar

Re: Draft Minutes from SIMPLE <at> IETF81


On Aug 5, 2011, at 10:19 PM, Ben Campbell wrote:

> The following are draft minutes from the SIMPLE meeting in Quebec. Please send any corrections as soon as possible.
> 

Looks like the session was recorded, right? If so, can someone point em to the audio file?

Thanks!

--
Saúl Ibarra Corretgé
AG Projects
Ben Campbell | 9 Aug 2011 23:02
Favicon

Re: Draft Minutes from SIMPLE <at> IETF81


On Aug 8, 2011, at 2:28 AM, Saúl Ibarra Corretgé wrote:

> 
> On Aug 5, 2011, at 10:19 PM, Ben Campbell wrote:
> 
>> The following are draft minutes from the SIMPLE meeting in Quebec. Please send any corrections as soon as possible.
>> 
> 
> Looks like the session was recorded, right? If so, can someone point em to the audio file?
> 

https://www.ietf.org/audio/ietf81/ietf81-204b-20110729-1256-pm.mp3 . That's for the whole
afternoon. The SIMPLE meeting starts at about 1:19

Thanks!

Ben.

> Thanks!
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
> 
> _______________________________________________
> Simple mailing list
> Simple <at> ietf.org
(Continue reading)

Ben Campbell | 10 Aug 2011 14:51
Favicon

Test Message, Please Ignore

No Content
Eric Burger | 22 Aug 2011 18:37

TLS or Not for CEMA

The CEMA draft, the latest incarnation of session matching, is almost ready for submission.  As you may
recall from the list and live discussion in Quebec City (archived and minuted), the point of CEMA is not to
make life easy for middleboxes.  The point is to make it *possible* for end-to-end encryption to occur in
the common topology where there happen to be middleboxes.  A side effect is life is a lot easier for
middleboxes, which one could consider the carrot to get the middlebox manufacturers and service
providers to adopt CEMA, is it makes life easier for them.

Because the purpose of CEMA is enabling end-to-end encryption, there has been some debate as to whether,
when two CEMA-endpoints are negotiating, TLS is mandatory or optional.

On the optional side are the following arguments:

o   TLS consumes resources, more so than TCP

o   TLS requires certificates in the end point

o   Non-CEMA endpoints have only a MAY requirement for TLS, and thus few if any implement TLS

o   TLS does not provide bullet-proof security, due to vulnerabilities from self-signed certificates or
alternate root certificate hijacking

On the mandatory side are the following arguments:

o   While TLS consumes resources, most mobile devices have more than enough compute and battery resources to
do TLS.

o   TLS does not impact middleboxes whatsoever

o   The primary market for CEMA initially is 3GPP IMS.  In 3GPP IMS, all endpoints have rooted, trusted certificates.

(Continue reading)


Gmane