Subject: Re: [Sip] draft-ietf-sip-hop-limit-diagnostics-03

From: Scott Lawrence <[email-masked]>
Date: Mon, 03 Jul 2006 15:39:40 -0400

On Mon, 2006-06-26 at 09:00 -0700, Cullen Jennings wrote:
> On Jun 16, 2006, at 2:59 PM, Scott Lawrence wrote:
> 
> >
> > There are, I think, two issues remaining for discussion:
> 
> I disagree - I don't think the draft of the discussion has addressed  
> the issue I brought up.

I'm going to guess here - do you mean the issue of how large the
response should be?

There is text in the draft on _how_ to reduce the size of the response.

3261 does not provide guidance clear guidance on response size limits.
It _does_ say that all implementations MUST be able to handle messages
up to the maximum UDP packet size, which can probably handle even 70 hop
messages.  If you think that SIP needs better definition of _when_ to
limit response sizes and _what_ size they should be limited to, then I
think that's an interesting discussion, but it's a bigger question than
this error response and a problem that already exists whether this draft
is accepted or not.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

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

---

From: [email-masked]
Date: Mon, 3 Jul 2006 21:14:57 -0400

I'm thinking it would be a Good Thing to define a Content-Disposition
value for the message/sipfrag to unambiguously tag its purpose.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 01:45:13 -0400

inline.

> this error response and a problem that already exists whether this draft

Well, here is the history.

The transport design of SIP was based on the model that the response 
used the same transport as the request. We had the somewhat naive view 
that the response wouldn't be much larger than the request. So, we would 
take the MTU, subtract off a few hundred bytes to account for any 
possible increase in the size of the response, and that should be OK.

So, the implied limit is the path MTU itself, or 1500 bytes if unknown. 
But this is not stated explicitly, its implicit from the design.

One idea on dealing with the size problem is, instead of including the 
sip-frag in a response, the resposne just indicates that the hop limit 
was exceeded. The server which generated the response then sends a 
request in a totally new transaction, towards the contact of the 
request. That request contains the sip-frag with all of the information, 
and could be sent over TCP if needed.

That idea doesn't work for requests which omit contact, and also means 
that intermediate proxies on the path of the failed request might not 
see the diagnostic information, since it would come over a different 
transaction.

Anyway, just a thought.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Jul 2006 13:08:05 -0500

On Jul 7, 2006, at 12:45 AM, Jonathan Rosenberg wrote:

>
>
> One idea on dealing with the size problem is, instead of including  
> the sip-frag in a response, the resposne just indicates that the  
> hop limit was exceeded. The server which generated the response  
> then sends a request in a totally new transaction, towards the  
> contact of the request. That request contains the sip-frag with all  
> of the information, and could be sent over TCP if needed.
>
> That idea doesn't work for requests which omit contact, and also  
> means that intermediate proxies on the path of the failed request  
> might not see the diagnostic information, since it would come over  
> a different transaction.
>
> Anyway, just a thought.

JDR mentioned during today's WG discussion that he had previously  
suggested this idea on the list. I looked and found it hiding in a  
thread, and thought it was worth putting back up on the list.

So here you go. Maybe this will work.

--
Dean

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 13 Jul 2006 10:53:24 -0400

One of the open issues with draft-ietf-hop-limit-diagnostics-0x (for all
x <= 3) is that the response will usually be very large.  If any hop in
the path is UDP, and the large response reaches that point, it may be
fragmented into so many parts that it: 
 - causes congestion problems in the reverse direction
 - fails reassembly (resulting in no response at all and 
   triggering retries)
Since either of these problems is arguably worse than not getting good
diagnostic information, we have concluded that something different needs
to be done.

I've spent some time trying to sort through the various suggestions on
how to cope with this, and I think that the simplest one is the best.  I
propose something like the following for the next revision of the draft:

        When sending an error response that has a message/sipfrag body,
        the responding server MUST examine all the Via header values in
        the request.  If any Via header value specifies UDP, then the
        total size of the response body MUST NOT be greater than 200
        bytes and the server MUST follow the procedures in section X to
        prune the returned message/sipfrag body to fit within this
        limit.  If no request Via header value specifies UDP, then the
        server is free to either prune the returned message/sipfrag body
        as specified in section X or to return the full set of request
        headers.

Even though this falls short of providing as much diagnostic information
as I'd like, I think that this is the best chance of getting _some_
useful information back to both the originator and to the proxies along
the path.  It means that you have a better chance of getting better
diagnostic information when you use TCP, and I think that may actually
provide an incentive that's in a good direction anyway.

The above text does not attempt to solve the general problem of SIP
response size; it is deliberately limited to the class of diagnostic
responses this draft is advocating.  I think that the SIP WG should try
to actually specify general rules for response sizes, but I would rather
decouple that from making this diagnostic information available.

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 13 Jul 2006 17:21:04 +0200

Another option is to return, in the 4xx response, an http URI pointing 
to a place where the server has stored the request. The requester can 
then go and pull the SIP request.

Might be an issue to interdomain cases, but not sure.

Hisham

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 13 Jul 2006 14:12:24 -0400

> >> I

On Thu, 2006-07-13 at 17:47 +0200, Jeroen van Bemmel wrote:
> gzip on the body might help too

If I'm not mistaken, it's not trivial to figure out how much any given
text will compress with gzip unless you actually try each possibility. 

I'd rather preserve the human-readability and get one fewer headers.

Also, it doesn't do all that well on short inputs.

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 13 Jul 2006 14:15:38 -0400

> Might be an issue to interdomain cases, but not sure.

I'm fairly sure that it would often be a problem.  

Even if all I get is the warning header, the request line and the
topmost via, I suspect it's more useful than a URL I might not be able
to reach (and I suspect that the URLs would often not be short).  

I also don't want to require that a proxy also be an http server in
order to provide this functionality.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Jul 2006 14:20:51 -0400

Hi Hisham,
I don't like the http URI concept for that because of the security,
performance, and reachability issues.  I imagine that intermediate nodes in
the return path may well want to log the diags info for certain response
failures, without user intervention.  With a mime attachment no problem
(well, no more than other sip/mime issues).  With an http uri it's an issue
for a bunch of probably obvious reasons.  I'd rather not have to create
diags/logs for the diags problems.  :)
Cheers,
-hadriel

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 11:21 AM
> To: Scott Lawrence
> Cc: SIP WG List
> Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 13 Jul 2006 14:35:44 -0500

Hi,

Inline below.

Thx
Samir

<< Removed Unrelated stuff>>

> If I'm not mistaken, it's not trivial to figure out how much 
> any given text will compress with gzip unless you actually 
> try each possibility. 
> 

SS>>  Gzip can achieve good compression ratio, if there are loops and
hop (RR, Via ) entries are repeated multiple times. Or should it be for
sigcomp ??

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jul 2006 15:25:21 -0400

This is a function we want to be implemented universally in proxies. So 
we don't want to raise the bar at all high. Incorporating a web server 
into every proxy seems to raise the bar. And retaining the message so it 
can be retrieved, without any clear idea how long that will be is 
another problem. There is a lot of attraction to just sending the 
response and forgetting it.

	Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 13 Jul 2006 14:46:06 -0500

Inline.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 2:21 PM
> To: 'Hisham Khartabil'; 'Scott Lawrence'
> Cc: 'SIP WG List'
> Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses
> 
> Hi Hisham,
> I don't like the http URI concept for that because of the 
> security, performance, and reachability issues.  I imagine 
> that intermediate nodes in the return path may well want to 
> log the diags info for certain response failures, without 
> user intervention.  With a mime attachment no problem (well, 
> no more than other sip/mime issues).  With an http uri it's 
> an issue for a bunch of probably obvious reasons.  I'd rather 
> not have to create diags/logs for the diags problems.  :) 
> Cheers, -hadriel
> 

SS>> Nobody wants to handle cascaded faults, diagnostics. If http
operation fails, that's it. Stop.

Apart from security concerns (Which may be asserted with SAML etc, I am
not sure as of now), what other concerns you have.

Thx
Samir

<< Removed unrelated stuff >>

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 13 Jul 2006 15:51:16 -0400

> hop (RR, Via ) entries are repeated multiple times. Or should it be for

My point was that the output of the gzip compression would have to be
less than 201 bytes.  You can't just truncate gzip output at any byte
boundary, so you'd have to select some part of the message to compress
and see if you got <201, then try again if you didn't, etc.  Too
complex.

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 13 Jul 2006 14:50:20 -0500

Fine. So what options are left ? Only compression or prunning.

IMHO, how proxies are configured. They must be having the web interface
for the configuration.

Or they are just plain old vanila text file/cmd line configuration
entities.

Thx
Samir 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 3:25 PM
> To: Hisham Khartabil
> Cc: SIP WG List
> This is a function we want to be implemented universally in 
> proxies. So we don't want to raise the bar at all high. 
> Incorporating a web server into every proxy seems to raise 
> the bar. And retaining the message so it can be retrieved, 
> without any clear idea how long that will be is another 
> problem. There is a lot of attraction to just sending the

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 13 Jul 2006 15:18:28 -0500

> My point was that the output of the gzip compression would 
> have to be less than 201 bytes.  You can't just truncate gzip 
> output at any byte boundary, so you'd have to select some 
> part of the message to compress and see if you got <201, then 
> try again if you didn't, etc.  Too complex.

 I was not asking to truncate the compressed output. Options available
are

  1) use sigcomp everywhere. And everything has limits, so it may not
help too in the extreme situations.

  2) http indirection

  3) At any hop, where proxy finds out that response will be increased
further going down, it just rejects the request rightaway asking for a
different transport. This check should be done before MAX-FORWARD check.
When proxy will be doing this, it will not have to attach the response
like in 483 in the body. It is different error code. I am not sure on
this what 3261 says. As we are changing the 3261 behaviour for 483
response, can we do this ? Backward compatibility ??

Thx
Samir

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Jul 2006 16:14:16 -0500

>         as specified in section X or to return the full set of request

Since UDP is the default, you may need this to say "Does not specify  
TCP, TLS, or SCTP".

Also, this will still explode in environments where evil topology- 
hiding functions (common in SBCs) have suppressed the Via header  
fields. Some people would have me believe that this occurs in most if  
not all IMS deployments, giving us a low probability that large  
responses will ever actually work.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Jul 2006 19:31:08 -0400

That's not a problem, in terms of fragmentation.  They'll probably strip the
attachment anyway.  Or at least that's my guess. (I tried to say that in the
meeting)

I don't see much choice - it's too obvious a place to have all sorts of
internal sensitive headers exposed. (for example, generate a request into an
IMS network that you know will fail and trigger this diags response, and
learn about P-headers and trunk-group-ids and other fun things)  It's called
topology hiding for a reason.  :)

One could argue the most likely party capable of actually rectifying the
problem which caused the response is the same IMS network operator who
strips them.  So as long as the stripping device logged them they'll at
least have the info. (hence my previous email on logging them on proxies) 

-hadriel

> From: Dean Willis [mailto:[email-masked]]
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 13 Jul 2006 17:47:20 +0200

Regards,

Jeroen

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 14 Jul 2006 00:01:00 -0500

Joren,

If it is good case where all hops are different, what will be the
compression ratio ?

If it is looping/spiraling, then it will be having good compression
ratio for 483. 

What about in general (No hop limit use case, no body in the response)
where response size is big ?

Thx
Samir   

> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 11:47 AM
> To: Hisham Khartabil; Scott Lawrence
> Cc: SIP WG List

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 14 Jul 2006 08:56:23 +0200

Samir,

I was thinking specifically for the 483 case, reporting the via sequence.

You have {200 + the size of the original body + request headers that you can 
omit + savings from using short header forms} to respond with, perhaps a 
simple text-based run-length encoding scheme could work as well.

E.g.

111.222.111.222:1234/UDP,111.222.111.223:1234/UDP,17(111.222.111.224:1234/UDP,111.222.111.225:1234/UDP),17(111.222.111.224:1234/TCP,111.222.111.225:1234/TCP)

FQDNs could be slightly longer, but assuming about 40 bytes per entry, you 
could report at least 5 (omitting the last one (UA itself) and the 
one-but-last one, since the UA will know those). Perhaps omitting the 
transport (port too?) (UA will know initial transport, if required only the 
moment of transistion could be encoded). Then you could report 10 entries 
easily. Add to that a string host encoding:

1=111.222.111.222:1234
2=111.222.111.223:1234
3=111.222.111.224:1234
4=111.222.111.225:1234

1,2,34(3,4)

Regards,

Jeroen

----- Original Message ----- 
From: "Samir Srivastava" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Hisham Khartabil" 
<[email-masked]>; "Scott Lawrence" <[email-masked]>
Cc: "SIP WG List" <[email-masked]>
Sent: Friday, July 14, 2006 7:01 AM
Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses

Joren,

Thx
Samir

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 14 Jul 2006 02:13:20 -0500

Hi,

There was discussion in the meeting, whether response message exceeding
should be fixed in general or 483 only.

Chairs (Dean) said that Hop limit diagnostics cannot move without that
fix.

Thx
Samir 

> Sent: Friday, July 14, 2006 2:56 AM
> To: Srivastava, Samir (SC100:8826); Hisham Khartabil; Scott Lawrence
> Cc: SIP WG List
> You have {200 + the size of the original body + request 
> headers that you can omit + savings from using short header 
> forms} to respond with, perhaps a simple text-based 
> run-length encoding scheme could work as well.
> 
> E.g.
> 
> 111.222.111.222:1234/UDP,111.222.111.223:1234/UDP,17(111.222.1
> 11.224:1234/UDP,111.222.111.225:1234/UDP),17(111.222.111.224:1
> 234/TCP,111.222.111.225:1234/TCP)
> 
> FQDNs could be slightly longer, but assuming about 40 bytes 
> per entry, you could report at least 5 (omitting the last one 
> (UA itself) and the one-but-last one, since the UA will know 
> those). Perhaps omitting the transport (port too?) (UA will 
> know initial transport, if required only the moment of 
> transistion could be encoded). Then you could report 10 
> entries easily. Add to that a string host encoding:
> 
> 1=111.222.111.222:1234
> 2=111.222.111.223:1234
> 3=111.222.111.224:1234
> 4=111.222.111.225:1234
> 
> 1,2,34(3,4)
> 
> Regards,
> 
> Jeroen
> 
>

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 14 Jul 2006 09:56:21 -0400

> Chairs (Dean) said that Hop limit diagnostics cannot move without that

The guidance I have received is that we cannot proceed with specifying a
new diagnostic response behavior without at least limiting the size of
the responses it generates for paths that include UDP.  

We are not required (and have not attempted in the proposed text) to
solve the problem of response sizes in general.

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 14 Jul 2006 10:10:46 -0400

> help too in the extreme situations.

I believe that requiring sigcomp support in a proxy in order to provide
these responses would be too large a barrier to deployment.  I want this
to be so easy that lots of implementations will do it quickly.

>   2) http indirection

I think this has been dealt with.

> response, can we do this ? Backward compatibility ??

There is no way for a proxy to detect that a request would fail further
along the path.

Yes, we are updating what 3261 says.  I have been doing interoperability
testing of a variant of these responses for 2 years and (other than the
UDP size problem), have not encountered any UA that had a problem with
these responses (even ones that had _lots_ of other problems with
perfectly valid SIP).

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 14 Jul 2006 10:03:05 -0400

> I was thinking specifically for the 483 case, reporting the via sequence.

This is another issue that I'll start a thread on soon, but I'd like to
be able to send this kind of diagnostic response for some other errors
as well, and any solution to the size question should, I think, be
independent of the error type.

> simple text-based run-length encoding scheme could work as well.

I believe that it is important to minimize the manipulation of the
returned diagnostic information because that introduces opportunities
for the rejecting server to misrepresent the request, which adds to the
problem.

Pruning the response is (alas) unavoidable given UDP.  The
message/sipfrag specification (as I understand it) allow for modifying
the message only by removing entire headers, and I think that's the most
we should do.

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 14 Jul 2006 09:48:23 -0400

> Since UDP is the default, you may need this to say "Does not specify  

I don't believe that we're in danger of the SIP standard adding any
other transports that share the unreliable and network-hostile
characteristics of UDP, but it seems likely that there will in the
future be other reliable transports that can cope with large responses,
so I'd prefer to express this in a way that doesn't need to be updated
when that happens.

Would it be more clear to replace 'specifies UDP' with 'indicates that
UDP is used' ?

> responses will ever actually work.

People who deploy such things and don't keep them up to date when the
protocol changes deserve what happens to them.  I don't think that we
need to maintain backward compatibility or otherwise protect the
clueless from implementations that have chosen (for, I am sure, good
and/or revenue-generating reasons) to violate MUST-level rules.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 14 Jul 2006 15:16:08 -0400

> From: Scott Lawrence [mailto:[email-masked]]
> 

Actually, I think his point was that such evil practices will impact _your_
non-evil providers/UAs.  And I take back what I said about it not being a
problem, because I see Dean's point now and can think of how it can be a
problem.  The problem is if you're a good guy calling _through_ an evil
provider (unbeknownst to you) transiting to other good providers.

If the loop is in the other good provider, and they implement this draft,
but the evil one doesn't strip the attachment, then the extra-large response
may not get back to you because of UDP issues.  So you'll not get the final
response, and have a bad calling experience, and create issues for the good
provider as well.  That's not good, for the good guys.  While I know at
least some Via-hiding boxes can strip the attachment out, that doesn't mean
all of them will/can.  

So perhaps you should size-limit all responses.  The odds of some hop or
other not being UDP isn't that good anyway today, and not many will want to
implement a draft which negatively impacts them for even a subset of cases.
Though I would like TCP-usage to get the benefit of TCP to promote its use
in the future, if you want rapid ubiquitous adoption of this draft mechanism
then you have to co-exist with such use cases, IMHO.  

-hadriel

---

From: [email-masked]
Date: Fri, 14 Jul 2006 23:05:07 -0400

From: Scott Lawrence <[email-masked]>

I just googled up a few web pages and e-mail archives containing a
total of 56 of SIP messages, extracted them, and ran gzip on them.  It
turns out that gzip compresses them poorly -- the median compression
is 70% (compressed size / original size); 67% is at about the 25th
percentile.  My guess is that many of the longer fields are
authentication, call-ID, and branch-parameter fields, all of which are
pseudo-random.

Dale

---

From: [email-masked]
Date: Fri, 14 Jul 2006 23:15:45 -0400

If we're going to this level of complexity, the right mechanism would
likely be a SUBSCRIBE that gets a return NOTIFY containing the failed
message -- using SIP to retrieve the message means that the
interdomain issues are likely to be solved already.

But I think that raises the bar for implementation too high -- people
are unlikely to invest in installing that amount of machinery until
the utility of the meachanism is proven.  Let's implement the
straightforward response body now.

Later, if we decide a "remote retrival" mechanism would be useful,
define how to put the branch-parameter from the top Via of the failing
request in a SUBSCRIBE to retrieve the whole message...

Dale

---

From: [email-masked]
Date: Fri, 14 Jul 2006 23:29:46 -0400

No, it won't, because most of the bytes in Via headers are in the
branch parameters, which are all different, even when the message
loops.

Fortunately, a rather good job of pruning can be done by a simple
algorithm:  Sort all the headers by a weighting that says how valuable
they are for diagnostics.  The sort needs to be stable, in that all
headers of the same type have their order preserved.  Then retain an
initial subset of the headers without going over the desired body
length.

The ordering of the headers will be something like this:

Most valuable:	Via

		Accept-*

		Content-*

Least valuable:	To
		From
		CSeq
		Call-ID
		Max-Forwards
		Contact
		Allow

The last group of headers can always be omitted, even if you have no
length restriction, because the UAC can reconstruct them, either (1)
it is identical to the same header in the response, (2) it is
generated with the same value in every request by the UAC, or (3) its
value is constant in this situation (e.g., Max-Forwards is 0).

Dale

---

From: [email-masked]
Date: Fri, 14 Jul 2006 23:36:25 -0400

> > hiding functions (common in SBCs) have suppressed the Via header

A representative of a company which makes evil devices mentioned to me
that the Evil Device (TM) will most likely entirely consume such a 483
response (after logging it for internal use), but then generate a
fresh 483 as if it came from the Evil Device at the point of entry to
the Walled Garden (TM).

This actually handles the separation of concerns sensibly -- If the
routing error is inside of the Walled Garden, the Evil Device's log
will capture the information that the Walled Garden's management will
need to fix the problem.  If due to some obscurity, the error happened
before the request entered into the Walled Garden and generated a
bogus request to the Walled Garden domain which caused the Walled
Garden to fail, then a 483 from the Evil Device will show everything
needed to diagnose the problem (including the request-URI at the point
of entry to the Walled Garden).

The messy case is when the loop goes through the Walled Garden but is
not entirely contained by it, though correlating the logs of all the
Even Devices should reveal the problem.

Dale

---

From: Dean Willis <[email-masked]>
Date: Sat, 15 Jul 2006 00:23:45 -0500

> so I'd prefer to express this in a way that doesn't need to be updated

I'll buy that.

> Would it be more clear to replace 'specifies UDP' with 'indicates that

There's probably some variation of language that would work here  
without saying TCP, etc.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 15 Jul 2006 17:56:22 +0200

Dale,

see inline

Regards,

jeroen

> branch parameters, which are all different, even when the message

I would say: prune those Via branch parameters. The only useful information 
they possibly provide, is whether the element is RFC3261 compliant or not. 
So take the first 7 chars of each via branch, and strip the rest.

Then compression will be better too, the only problem is that the sender 
needs to support it (or at least be capable to log binary messages)

> The ordering of the headers will be something like this:

Add to this: the resulting request URI, Record-Route headers (many proxies 
append state in those, which might help) and Route headers. And as above, 
limit via branches to 7 chars (or even less, eg replace them with '1' or '0' 
depending on whether the magic cookie was there. Retain other parameters, 
such as 'alias' which might indicate that connection reuse is happening)

> Accept-*

including Accept-Contact and Reject-Contact, although in general all these 
UAC-inserted headers are less valuable; many UACs will either still have the 
original request (for retransmissions, in particular for UDP) or be able to 
reconstruct it.

> Contact

You'd perhaps also want any Contact header (though the UAC might reconstruct 
that). It could contain callee capabilities that explain why the request was 
routed in a particular way.

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 16 Jul 2006 11:46:17 -0400

> So take the first 7 chars of each via branch, and strip the rest.

There are two reasons I don't like this approach:

1) The message/sipfrag definition does not allow header fields to be
modified - just removed or included as is.

2) The branch parameters may well be useful to correlate information in
log files (in fact, they may also have information coded into them that
can be read by someone who knows how they are constructed).

> needs to support it (or at least be capable to log binary messages)

None of which addresses the fact that you cannot easily predict how much
of the message to include so that you get <201 bytes out of the
compressor.

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 16 Jul 2006 11:50:43 -0400

> initial subset of the headers without going over the desired body

The more complicated the algorithm, the more chance of introducing
errors that confuse rather than illuminate.  I'd rather send back less
but preserve all ordering than risk corrupting the information that does
get back.  Bad diagnostic information is worse than no diagnostic
information.   The key word is 'simple'.

I will propose some additional text for the pruning section to recommend
removing those headers that are identical to those in the returned
response (call-id, cseq, etc).

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 16 Jul 2006 12:05:07 -0400

> then you have to co-exist with such use cases, IMHO.  

I think that crippling a useful feature to allow for elements that
blatantly violate the rules is going too far.  

In the scenario you describe, it will be pretty easy to detect that the
problem occurs on the other size of the evilbox and that the evilbox has
prevented the response from getting back, because if you do the
progressive hop-limit trick it will show that you get responses from
everywhere along the path until you get above the size limit.

In any event, the proposed text says:

        If no request Via header value specifies UDP, then the
        server is free to either prune the returned message/sipfrag body
        as specified in section X or to return the full set of request
        headers.

so if an implementation wishes to always prune to under 200, it is free
to do so and avoid even this potential problem.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 16 Jul 2006 18:09:39 +0200

Hi Scott,

> modified - just removed or included as is.

OK, so then perhaps either the message/sipfrag definition needs to be fixed 
as well, or message/sipfrag is not fit for the purpose we have here. 
"message/sipfrag-pruned" ?

> can be read by someone who knows how they are constructed).

Yes, all information may potentially be helpful. The problem is (as I'm sure 
you're aware of): "Somethin' 's gotta give". In my opinion, if the choice is 
between removing via's starting from the bottom (as the current draft 
suggests, such that the UA can detect that something is missing) or removing 
branch parameters until it fits, I'd rather have all via headers without 
branches. That for sure is something the UA can interpret, as opposed to a 
proprietary branch-encoded scheme which is much less likely to be 
understood. If desired, you could start with all vias including branches, 
and start pruning branch parameters first (so you'd still have some branch 
parameters left, preferrably at the bottom I would say)

> of the message to include so that you get <201 bytes out of the

Perhaps a streaming compressor like deflate (RFC1950) would then be better. 
I'm no expert, but I believe you could cut that off when you reach the 
maximum size?

Regards,

Jeroen

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 16 Jul 2006 13:02:36 -0400

On Sun, 2006-07-16 at 18:09 +0200, Jeroen van Bemmel wrote:
> you're aware of): "Somethin' 's gotta give".

My choice would be UDP (only half :-) )

>  In my opinion, if the choice is 
> branches. 

On long paths, you won't have room for that in 200 bytes anyway.

> That for sure is something the UA can interpret, as opposed to a 
> understood. 

I don't actually hope for UAs to interpret this - just human beings.

---

From: [email-masked]
Date: Mon, 17 Jul 2006 19:37:06 -0400

From: "Jeroen van Bemmel" <[email-masked]>

This idea has advantages.  But it branches into the territory of
revising the definition of message/sipfrag, and possibly dinking with
parsers for it.

As for compression, in theory one could add a Content-Encoding header
-- but again, that's burdening implementations.  Most compression
algorithms are stream-oriented, and one could order the headers
according to importance, then start compressing, and chop the output
at 200 bytes.  But again, you'd force implementations to have a gzip
decompresser that returns "the output so far" rather than just an
error indication.

IMHO, the primary design goal is to make it *easy* to deploy this
mechanism widely.  After it has proven its worth, and attracted
significant commitment from implementors -- and we've discovered what
the problems with it are *in practice* -- then redesign for better
performance.

"First make it work.  Then make it fast."

Presumably the Contact header in the failed request has the same value
as was put there when the UAC sent the request.  The response should
contain a Contact, of course, but that's not what we're talking about.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 18 Jul 2006 01:49:47 +0200

Simplest and fastest is probably: for UDP, return the warning and as much as 
will fit in ( 200 + Content-Length ) bytes
To get more diagnostics, send the request again using TCP (similar to 
authentication challenge but different transport)

Trade-off is that there is no guarantee that the same thing will happen (but 
likely).

Of course you can still add things like "if sender supports deflate, it is 
recommended to use that"

Regards,

jeroen

---

From: [email-masked]
Date: Mon, 17 Jul 2006 20:59:30 -0400

Of course you can still add things like "if sender supports
   deflate, it is recommended to use that"

Ah, yes.  And conveniently, there is an "Accept-Encoding" header for
the UAC to indicate just that.

Dale

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 18 Jul 2006 09:25:16 -0400

> the UAC to indicate just that.

But since that applies generically to any response, I don't think there
is any need to call it out specifically here.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Jul 2006 08:59:11 -0700

> text will compress with gzip unless you actually try each possibility.

I suspect you could use LZ77 (the gzip algo) in a streaming mode or  
select some other streaming compression technique to solve this so  
you add each header in order until it gets too big then use the  
previous result.

However, I'm not arguing for this one way or the other - since this  
is meant to help humans debug, it seems like having it be easily  
human readable would be best.

Cullen (with my individual hat on)